Hi
Am 22.10.24 um 21:15 schrieb Pavel Machek:
Hi!
- interface for setting multiple LEDs at once
- interface for setting a range of LEDs at once
How are LEDs ordered? I don't believe range makes much sense.
Range would allow for efficiently changing the color of all LEDs. But i agree
that thi
Hi,
Am 22.10.24 um 17:02 schrieb Armin Wolf:
Am 22.10.24 um 11:37 schrieb Pavel Machek:
Hi!
Personally I really like the idea to just emulate a HID LampArray device
for this instead or rolling our own API. I believe there need to be
strong arguments to go with some alternative NIH API and I
Am 22.10.24 um 11:05 schrieb Benjamin Tissoires:
Sorry I should have answered earlier...
On Oct 09 2024, Werner Sembach wrote:
Resend because HTML mail ..., but I think I now know when Thunderbird does
it: Every time I include a link it gets converted.
Hi
Am 08.10.24 um 17:21 schrieb
Hi
Am 22.10.24 um 11:47 schrieb Pavel Machek:
Hi!
Sorry for taking a bit long to respond.
This "illumination" subsystem would (from my perspective) act like some sort of
LED subsystem
for devices with a high count of LEDs, like some RGB keyboards.
This would allow us too:
- provide an abstr
Resend because HTML mail ..., but I think I now know when Thunderbird does it:
Every time I include a link it gets converted.
Hi
Am 08.10.24 um 17:21 schrieb Benjamin Tissoires:
On Oct 08 2024, Werner Sembach wrote:
[...]
Yeah, it just means that you can query or send the data. You can also
Hi,
Am 08.10.24 um 17:33 schrieb Lee Jones:
On Mon, 07 Oct 2024, Werner Sembach wrote:
Am 07.10.24 um 14:58 schrieb Lee Jones:
On Fri, 04 Oct 2024, Werner Sembach wrote:
Am 03.10.24 um 09:59 schrieb Lee Jones:
On Wed, 02 Oct 2024, Werner Sembach wrote:
Hi,
Am 02.10.24 um 14:52 schrieb
Hi
Am 08.10.24 um 17:21 schrieb Benjamin Tissoires:
On Oct 08 2024, Werner Sembach wrote:
[...]
Yeah, it just means that you can query or send the data. You can also
use HIDIOCGINPUT() and HIDIOCSOUTPUT() to get a current input report and
set an output report through the hidraw ioctl
Am 08.10.24 um 14:18 schrieb Benjamin Tissoires:
On Oct 08 2024, Werner Sembach wrote:
Am 08.10.24 um 11:53 schrieb Benjamin Tissoires:
On Oct 07 2024, Werner Sembach wrote:
Hi,
Am 02.10.24 um 10:31 schrieb Benjamin Tissoires:
On Oct 01 2024, Werner Sembach wrote:
Hi Benjamin,
Am
Am 08.10.24 um 11:53 schrieb Benjamin Tissoires:
On Oct 07 2024, Werner Sembach wrote:
Hi,
Am 02.10.24 um 10:31 schrieb Benjamin Tissoires:
On Oct 01 2024, Werner Sembach wrote:
Hi Benjamin,
Am 01.10.24 um 15:41 schrieb Benjamin Tissoires:
[...]
PPS: sorry for pushing that hard on HID
Hi,
Am 02.10.24 um 10:31 schrieb Benjamin Tissoires:
On Oct 01 2024, Werner Sembach wrote:
Hi Benjamin,
Am 01.10.24 um 15:41 schrieb Benjamin Tissoires:
[...]
PPS: sorry for pushing that hard on HID-BPF, but I can see that it fits
all of the requirements here:
- need to be dynamic
- still
Am 04.10.24 um 16:46 schrieb Ilpo Järvinen:
On Fri, 4 Oct 2024, Werner Sembach wrote:
Am 03.10.24 um 12:54 schrieb Ilpo Järvinen:
On Wed, 2 Oct 2024, Werner Sembach wrote:
Am 02.10.24 um 11:52 schrieb Ilpo Järvinen:
On Tue, 1 Oct 2024, Werner Sembach wrote:
The TUXEDO Sirius 16 Gen1 and
Am 07.10.24 um 14:58 schrieb Lee Jones:
On Fri, 04 Oct 2024, Werner Sembach wrote:
Am 03.10.24 um 09:59 schrieb Lee Jones:
On Wed, 02 Oct 2024, Werner Sembach wrote:
Hi,
Am 02.10.24 um 14:52 schrieb Lee Jones:
On Fri, 27 Sep 2024, Werner Sembach wrote:
Hi,
first revision integrating
Am 03.10.24 um 09:59 schrieb Lee Jones:
On Wed, 02 Oct 2024, Werner Sembach wrote:
Hi,
Am 02.10.24 um 14:52 schrieb Lee Jones:
On Fri, 27 Sep 2024, Werner Sembach wrote:
Hi,
first revision integrating Armins feedback.
Stuff I did not yet change and did not comment on previously:
- Still
Hi Ilpo,
Am 03.10.24 um 12:54 schrieb Ilpo Järvinen:
On Wed, 2 Oct 2024, Werner Sembach wrote:
Am 02.10.24 um 11:52 schrieb Ilpo Järvinen:
On Tue, 1 Oct 2024, Werner Sembach wrote:
The TUXEDO Sirius 16 Gen1 and TUXEDO Sirius 16 Gen2 devices have a per-key
controllable RGB keyboard backlight
Am 02.10.24 um 11:52 schrieb Ilpo Järvinen:
On Tue, 1 Oct 2024, Werner Sembach wrote:
The TUXEDO Sirius 16 Gen1 and TUXEDO Sirius 16 Gen2 devices have a per-key
controllable RGB keyboard backlight. The firmware API for it is implemented
via WMI.
To make the backlight userspace configurable
Hi,
Am 02.10.24 um 14:52 schrieb Lee Jones:
On Fri, 27 Sep 2024, Werner Sembach wrote:
Hi,
first revision integrating Armins feedback.
Stuff I did not yet change and did not comment on previously:
- Still have to ask Christoffer why the mutex is required
- Still using acpi_size instad of
Hi Armin,
Am 01.10.24 um 18:45 schrieb Armin Wolf:
Am 01.10.24 um 15:41 schrieb Benjamin Tissoires:
On Oct 01 2024, Werner Sembach wrote:
(sorry resend because thunderbird made it a html mail)
Hi,
Am 30.09.24 um 19:06 schrieb Benjamin Tissoires:
On Sep 30 2024, Werner Sembach wrote
Hi Benjamin,
Am 01.10.24 um 15:41 schrieb Benjamin Tissoires:
On Oct 01 2024, Werner Sembach wrote:
(sorry resend because thunderbird made it a html mail)
Hi,
Am 30.09.24 um 19:06 schrieb Benjamin Tissoires:
On Sep 30 2024, Werner Sembach wrote:
[...]
Thinking about it, maybe it's n
off-by: Werner Sembach
Link:
https://lore.kernel.org/all/1fb08a74-62c7-4d0c-ba5d-648e23082...@tuxedocomputers.com/
---
MAINTAINERS | 6 +
drivers/platform/x86/Kconfig | 2 +
drivers/platform/x86/Makefile | 3 +
drivers/platfo
Just wanted to send my current state as previous version had a null pointer
dereference.
On this toppic, why does hdev have a hdev->driver_data and a
hdev->dev.driver_data which are not the same? I assume hdev->driver_data is for
the ll_driver and hdev->dev.driver_data for the driver?
Hi again,
Am 01.10.24 um 14:23 schrieb Werner Sembach:
(sorry resend because thunderbird made it a html mail)
Hi,
Am 30.09.24 um 19:06 schrieb Benjamin Tissoires:
On Sep 30 2024, Werner Sembach wrote:
[...]
Thinking about it, maybe it's not to bad that it only changes once udev is
(sorry resend because thunderbird made it a html mail)
Hi,
Am 30.09.24 um 19:06 schrieb Benjamin Tissoires:
On Sep 30 2024, Werner Sembach wrote:
[...]
Thinking about it, maybe it's not to bad that it only changes once udev is
ready, like this udev could decide if leds should be used or
Hi,
Am 30.09.24 um 19:06 schrieb Benjamin Tissoires:
On Sep 30 2024, Werner Sembach wrote:
[...]
Thinking about it, maybe it's not to bad that it only changes once udev is
ready, like this udev could decide if leds should be used or if it should
directly be passed to OpenRGB for ex
Hi,
Am 30.09.24 um 18:15 schrieb Benjamin Tissoires:
On Sep 30 2024, Werner Sembach wrote:
Am 28.09.24 um 12:05 schrieb Benjamin Tissoires:
On Sep 28 2024, Werner Sembach wrote:
Hi,
Am 28.09.24 um 09:27 schrieb Benjamin Tissoires:
On Sep 28 2024, Armin Wolf wrote:
Am 27.09.24 um 23:01
Am 28.09.24 um 12:05 schrieb Benjamin Tissoires:
On Sep 28 2024, Werner Sembach wrote:
Hi,
Am 28.09.24 um 09:27 schrieb Benjamin Tissoires:
On Sep 28 2024, Armin Wolf wrote:
Am 27.09.24 um 23:01 schrieb Pavel Machek:
Hi!
The TUXEDO Sirius 16 Gen1 and TUXEDO Sirius 16 Gen2 devices have a
Hi,
Am 28.09.24 um 09:27 schrieb Benjamin Tissoires:
On Sep 28 2024, Armin Wolf wrote:
Am 27.09.24 um 23:01 schrieb Pavel Machek:
Hi!
The TUXEDO Sirius 16 Gen1 and TUXEDO Sirius 16 Gen2 devices have a per-key
controllable RGB keyboard backlight. The firmware API for it is implemented
via WM
Hi,
Am 28.09.24 um 00:21 schrieb Armin Wolf:
Am 27.09.24 um 23:01 schrieb Pavel Machek:
Hi!
The TUXEDO Sirius 16 Gen1 and TUXEDO Sirius 16 Gen2 devices have a
per-key
controllable RGB keyboard backlight. The firmware API for it is
implemented
via WMI.
Ok.
To make the backlight userspace
Hi Pavel,
Am 27.09.24 um 23:01 schrieb Pavel Machek:
Hi!
The TUXEDO Sirius 16 Gen1 and TUXEDO Sirius 16 Gen2 devices have a per-key
controllable RGB keyboard backlight. The firmware API for it is implemented
via WMI.
Ok.
To make the backlight userspace configurable this driver emulates a
La
Hi,
Am 27.09.24 um 19:18 schrieb Armin Wolf:
Am 27.09.24 um 13:24 schrieb Werner Sembach:
Hi,
an additional question below
Am 27.09.24 um 08:59 schrieb Werner Sembach:
Hi,
Am 26.09.24 um 20:39 schrieb Armin Wolf:
Am 26.09.24 um 19:44 schrieb Werner Sembach:
[...]
+// We don't kn
edo_nb04_wmi_util.h
b/drivers/platform/x86/tuxedo/tuxedo_nb04_wmi_util.h
new file mode 100644
index 0..2765cbe9fcfef
--- /dev/null
+++ b/drivers/platform/x86/tuxedo/tuxedo_nb04_wmi_util.h
@@ -0,0 +1,112 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * This code gives functions to avoid code d
Hi Benjamin,
Am 27.09.24 um 18:08 schrieb Benjamin Tissoires:
On Sep 26 2024, Werner Sembach wrote:
Hi,
took some time but now a first working draft of the suggested new way of
handling per-key RGB keyboard backlights is finished. See:
https://lore.kernel.org/all/1fb08a74-62c7-4d0c-ba5d
: Christoffer Sandberg
Signed-off-by: Christoffer Sandberg
Signed-off-by: Werner Sembach
Link:
https://lore.kernel.org/all/1fb08a74-62c7-4d0c-ba5d-648e23082...@tuxedocomputers.com/
---
MAINTAINERS | 6 +
drivers/platform/x86/Kconfig | 2
: Christoffer Sandberg
Signed-off-by: Werner Sembach
Link:
https://lore.kernel.org/all/1fb08a74-62c7-4d0c-ba5d-648e23082...@tuxedocomputers.com/
---
MAINTAINERS | 6 +
drivers/platform/x86/Kconfig | 2 +
drivers/platform/x86/Makefile
Hi,
first revision integrating Armins feedback.
Stuff I did not yet change and did not comment on previously:
- Still have to ask Christoffer why the mutex is required
- Still using acpi_size instad of size_t in the util functions, because the
value is put directly into a struct using acpi_size
-
Hi,
an additional question below
Am 27.09.24 um 08:59 schrieb Werner Sembach:
Hi,
Am 26.09.24 um 20:39 schrieb Armin Wolf:
Am 26.09.24 um 19:44 schrieb Werner Sembach:
[...]
+// We don't know if the WMI API is stable and how unique the GUID is for
this ODM. To be on the safe
+// si
Hi,
Am 26.09.24 um 20:39 schrieb Armin Wolf:
Am 26.09.24 um 19:44 schrieb Werner Sembach:
The TUXEDO Sirius 16 Gen1 and TUXEDO Sirius 16 Gen2 devices have a per-key
controllable RGB keyboard backlight. The firmware API for it is implemented
via WMI.
To make the backlight userspace
-style?
Kind regards,
Werner Sembach
corresponding WMI calls. This is a new approach as the leds subsystem lacks
a suitable UAPI for per-key keyboard backlights, and like this no new UAPI
needs to be established.
Co-developed-by: Christoffer Sandberg
Signed-off-by: Christoffer Sandberg
Signed-off-by: Werner Sembach
Link:
https
Hi
Am 24.07.24 um 19:36 schrieb Pavel Machek:
Hi!
IMO working with the HID LampArray is the way forward. So I would
suggest to convert any non-HID RGB "LED display" that we are talking
about as a HID LampArray device through `hid_allocate_device()` in the
kernel. Basically what you are suggest
Hi
Am 24.07.24 um 19:36 schrieb Pavel Machek:
Hi!
IMO working with the HID LampArray is the way forward. So I would
suggest to convert any non-HID RGB "LED display" that we are talking
about as a HID LampArray device through `hid_allocate_device()` in the
kernel. Basically what you are suggest
Hi Benjamin,
Am 27.03.24 um 12:03 schrieb Benjamin Tissoires:
On Mar 26 2024, Werner Sembach wrote:
Hi all,
Am 26.03.24 um 16:39 schrieb Benjamin Tissoires:
On Mar 26 2024, Werner Sembach wrote:
Hi all,
Am 25.03.24 um 19:30 schrieb Hans de Goede:
[snip]
If the kernel already handles the
Am 25.03.24 um 11:41 schrieb Werner Sembach:
Hello everyone,
currently GPU offloading on Linux is handled via environment variables. Which
is a subpar experience for desktop files and might not be possible when using
launchers (i.e. Steam, Lutris, Heroic, etc.) that have no explicit support
Hi all,
Am 26.03.24 um 16:39 schrieb Benjamin Tissoires:
On Mar 26 2024, Werner Sembach wrote:
Hi all,
Am 25.03.24 um 19:30 schrieb Hans de Goede:
[snip]
If the kernel already handles the custom protocol into generic HID, the
work for userspace is not too hard because they can deal with a
Hi all,
Am 25.03.24 um 19:30 schrieb Hans de Goede:
[snip]
If the kernel already handles the custom protocol into generic HID, the
work for userspace is not too hard because they can deal with a known
protocol and can be cross-platform in their implementation.
I'm mentioning that cross-platfor
Hi Hans,
Am 25.03.24 um 15:18 schrieb Hans de Goede:
Hi Werner,
On 3/19/24 4:18 PM, Werner Sembach wrote:
Hi Hans,
Am 18.03.24 um 12:11 schrieb Hans de Goede:
Hi Werner,
Sorry for the late reply.
np
On 2/22/24 2:14 PM, Werner Sembach wrote:
Hi,
Thanks everyone for the exhaustive
Hi Benjamin,
Am 25.03.24 um 16:56 schrieb Benjamin Tissoires:
On Mar 25 2024, Hans de Goede wrote:
+Cc: Bentiss, Jiri
Hi Werner,
On 3/20/24 12:16 PM, Werner Sembach wrote:
Hi Hans and the others,
Am 22.02.24 um 14:14 schrieb Werner Sembach:
Hi,
Thanks everyone for the exhaustive feedback
Am 20.03.24 um 12:33 schrieb Werner Sembach:
Am 20.03.24 um 12:16 schrieb Werner Sembach:
Hi Hans and the others,
Am 22.02.24 um 14:14 schrieb Werner Sembach:
Hi,
Thanks everyone for the exhaustive feedback. And at least this thread is a
good comprehesive reference for the future
Am 20.03.24 um 12:16 schrieb Werner Sembach:
Hi Hans and the others,
Am 22.02.24 um 14:14 schrieb Werner Sembach:
Hi,
Thanks everyone for the exhaustive feedback. And at least this thread is a
good comprehesive reference for the future ^^.
To recap the hopefully final UAPI for complex
Hi Hans and the others,
Am 22.02.24 um 14:14 schrieb Werner Sembach:
Hi,
Thanks everyone for the exhaustive feedback. And at least this thread is a
good comprehesive reference for the future ^^.
To recap the hopefully final UAPI for complex RGB lighting devices:
- By default there is a
Hi Hans,
Am 18.03.24 um 12:11 schrieb Hans de Goede:
Hi Werner,
Sorry for the late reply.
np
On 2/22/24 2:14 PM, Werner Sembach wrote:
Hi,
Thanks everyone for the exhaustive feedback. And at least this thread is a good
comprehesive reference for the future ^^.
To recap the hopefully
Hi,
Am 21.02.24 um 23:17 schrieb Pavel Machek:
Hi!
so after more feedback from the OpenRGB maintainers I came up with an even
more generic proposal:
https://gitlab.com/CalcProgrammer1/OpenRGB/-/issues/3916#note_1753072869
evaluate-set-command ioctl taking:
{
enum command /
et me know your thoughts and hopefully I can start implementing it soon for one
of our devices.
Kind regards,
Werner Sembach
Hi,
so after more feedback from the OpenRGB maintainers I came up with an even more
generic proposal:
https://gitlab.com/CalcProgrammer1/OpenRGB/-/issues/3916#note_1753072869
Copy pasting the relevant part:
>Another, yet more generic, approach:
>
>```
>get-device-info ioctl returning:
>{
>
Hi,
so I combined Hans last draft, with the discussion since then and the comments
from the OpenRGB maintainers from here
https://gitlab.com/CalcProgrammer1/OpenRGB/-/issues/3916 and my own experience
and came up witrh this rough updated draft for the new uapi:
Future handling of complex RGB
Hi,
Am 30.01.24 um 19:35 schrieb Hans de Goede:
Hi,
On 1/30/24 19:09, Werner Sembach wrote:
Hi Hans,
resend because Thunderbird htmlified the mail :/
I use thunderbird too. If you right click on the server name
and then go to "Settings" -> "Composition & Addres
Hi Hans,
resend because Thunderbird htmlified the mail :/
Am 30.01.24 um 18:10 schrieb Hans de Goede:
Hi Werner,
On 1/30/24 12:12, Werner Sembach wrote:
Hi Hans,
Am 29.01.24 um 14:24 schrieb Hans de Goede:
I think that are mostly external keyboards, so in theory a possible cut could
Hi Hans,
Am 30.01.24 um 18:10 schrieb Hans de Goede:
Hi Werner,
On 1/30/24 12:12, Werner Sembach wrote:
Hi Hans,
Am 29.01.24 um 14:24 schrieb Hans de Goede:
I think that are mostly external keyboards, so in theory a possible cut could
also between built-in and external devices.
IMHO it
Hi Hans,
Am 29.01.24 um 14:24 schrieb Hans de Goede:
Hi Werner,
On 1/19/24 17:04, Werner Sembach wrote:
Am 19.01.24 um 09:44 schrieb Hans de Goede:
So my proposal would be an ioctl interface (ioctl only no r/w)
using /dev/rgbkbd0 /dev/rgbkdb1, etc. registered as a misc chardev.
For per
Am 19.01.24 um 23:14 schrieb Pavel Machek:
Hi!
And while I would personally hate it, you can imagine a use case where
you'd like a keypress to have a visual effect around the key you
pressed. A kind of force feedback, if you will. I don't actually know,
and correct me if I'm wrong, but feels
Hi,
Am 19.01.24 um 21:15 schrieb Pavel Machek:
Hi!
2. Implement per-key keyboards as auxdisplay
- Pro:
- Already has a concept for led positions
- Is conceptually closer to "multiple leds forming a singular entity"
- Con:
- No preexisting UPower suppor
Hi,
Am 19.01.24 um 11:51 schrieb Jani Nikula:
On Fri, 19 Jan 2024, Hans de Goede wrote:
For per key controllable rgb LEDs we need to discuss a coordinate
system. I propose using a fixed size of 16 rows of 64 keys,
so 64x16 in standard WxH notation.
And then storing RGB in separate bytes, so u
Hi,
sorry have to resend, thunderbird html-ified the mail
Am 19.01.24 um 09:44 schrieb Hans de Goede:
Hi,
On 1/18/24 18:45, Pavel Machek wrote:
Hi!
We have an upcoming device that has a per-key keyboard backlight, but does
the control completely via a wmi/acpi interface. So no usable hidraw
Hi,
Am 19.01.24 um 09:44 schrieb Hans de Goede:
Hi,
On 1/18/24 18:45, Pavel Machek wrote:
Hi!
We have an upcoming device that has a per-key keyboard backlight, but does
the control completely via a wmi/acpi interface. So no usable hidraw here
for a potential userspace driver implementation .
Hi
Am 18.01.24 um 18:45 schrieb Pavel Machek:
Hi!
We have an upcoming device that has a per-key keyboard backlight, but does
the control completely via a wmi/acpi interface. So no usable hidraw here
for a potential userspace driver implementation ...
So a quick summary for the ideas floating
Hi Hans and Armin,
Am 17.01.24 um 20:03 schrieb Armin Wolf:
Am 17.01.24 um 17:50 schrieb Hans de Goede:
Hi All,
On 11/27/23 11:59, Werner Sembach wrote:
I also stumbled across a new Problem:
We have an upcoming device that has a per-key keyboard backlight, but does
the control
Hi,
Am 10.01.24 um 18:15 schrieb Andri Yngvason:
Hi Werner,
mið., 10. jan. 2024 kl. 13:14 skrifaði Werner Sembach
:
Hi,
Am 10.01.24 um 14:09 schrieb Daniel Vetter:
On Wed, 10 Jan 2024 at 13:53, Andri Yngvason wrote:
mið., 10. jan. 2024 kl. 11:10 skrifaði Daniel Vetter :
On Tue, Jan 09
Hi,
Am 10.01.24 um 14:42 schrieb Andri Yngvason:
mið., 10. jan. 2024 kl. 13:09 skrifaði Werner Sembach:
Hi,
Am 10.01.24 um 11:11 schrieb Andri Yngvason:
Hi,
mið., 10. jan. 2024 kl. 09:27 skrifaði Maxime Ripard:
On Tue, Jan 09, 2024 at 06:11:02PM +, Andri Yngvason wrote:
From: Werner
Hi,
Am 09.01.24 um 19:10 schrieb Andri Yngvason:
From: Werner Sembach
Add a new general drm property "active color format" which can be used by
graphic drivers to report the used color format back to userspace.
There was no way to check which color format got actually used on a giv
Hi,
Am 10.01.24 um 14:09 schrieb Daniel Vetter:
On Wed, 10 Jan 2024 at 13:53, Andri Yngvason wrote:
mið., 10. jan. 2024 kl. 11:10 skrifaði Daniel Vetter :
On Tue, Jan 09, 2024 at 06:11:00PM +, Andri Yngvason wrote:
+ /* Extract information from crtc to communicate it to userspace as
Hi,
Am 10.01.24 um 11:11 schrieb Andri Yngvason:
Hi,
mið., 10. jan. 2024 kl. 09:27 skrifaði Maxime Ripard :
On Tue, Jan 09, 2024 at 06:11:02PM +, Andri Yngvason wrote:
From: Werner Sembach
Add a new general drm property "preferred color format" which can be used
by userspa
Hi Hans & the others,
[snip]
I also stumbled across a new Problem:
We have an upcoming device that has a per-key keyboard backlight, but does the
control completely via a wmi/acpi interface. So no usable hidraw here for a
potential userspace driver implementation ...
So a quick summary for
Hi Hans,
Am 22.11.23 um 19:34 schrieb Hans de Goede:
Hi Werner,
[snip]
Another idea I want to throw in the mix:
Maybe the kernel is not the right place to implement this at all. RGB stuff is
not at all standardized and every vendor is doing completely different
interfaces, which does not fi
Am 21.11.23 um 13:20 schrieb Hans de Goede:
Hi Werner,
On 11/21/23 12:33, Werner Sembach wrote:
Hi,
Am 20.11.23 um 21:52 schrieb Pavel Machek:
Hi!
So... a bit of rationale. The keyboard does not really fit into the
LED subsystem; LEDs are expected to be independent ("hdd led")
Hi,
Am 20.11.23 um 21:52 schrieb Pavel Machek:
Hi!
So... a bit of rationale. The keyboard does not really fit into the
LED subsystem; LEDs are expected to be independent ("hdd led") and not
a matrix of them.
Makes sense.
We do see various strange displays these days -- they commonly have
ro
Hi,
coming from the leds mailing list I'm writing with Pavel how to best handle
per-key RGB keyboards.
His suggestion was that it could be implemented as an aux display, but he also
suggested that I ask first if this fits.
The specific keyboard RGB controller I want to implement takes 6*21
Am 23.02.23 um 19:56 schrieb Werner Sembach:
Am 23.02.23 um 19:26 schrieb Hogander, Jouni:
On Wed, 2023-02-22 at 15:17 +0100, Werner Sembach wrote:
On these Barebones PSR 2 is recognized as supported but is very
buggy:
- Upper third of screen does sometimes not updated, resulting in
Am 23.02.23 um 19:56 schrieb Werner Sembach:
Am 23.02.23 um 19:26 schrieb Hogander, Jouni:
On Wed, 2023-02-22 at 15:17 +0100, Werner Sembach wrote:
On these Barebones PSR 2 is recognized as supported but is very
buggy:
- Upper third of screen does sometimes not updated, resulting in
Am 23.02.23 um 19:26 schrieb Hogander, Jouni:
On Wed, 2023-02-22 at 15:17 +0100, Werner Sembach wrote:
On these Barebones PSR 2 is recognized as supported but is very
buggy:
- Upper third of screen does sometimes not updated, resulting in
disappearing cursors or ghosts of already closed
Am 23.02.23 um 07:27 schrieb Hogander, Jouni:
On Wed, 2023-02-22 at 15:13 -0500, Rodrigo Vivi wrote:
On Wed, Feb 22, 2023 at 03:17:55PM +0100, Werner Sembach wrote:
On these Barebones PSR 2 is recognized as supported but is very
buggy:
- Upper third of screen does sometimes not updated
Am 22.02.23 um 15:17 schrieb Werner Sembach:
On these Barebones PSR 2 is recognized as supported but is very buggy:
- Upper third of screen does sometimes not updated, resulting in
disappearing cursors or ghosts of already closed Windows saying behind.
- Approximately 40 px from the bottom
is flickering.
PSR 1 is working fine however.
Signed-off-by: Werner Sembach
Cc:
---
drivers/gpu/drm/i915/display/intel_quirks.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_quirks.c
b/drivers/gpu/drm/i915/display/intel_quirks.c
index
is flickering.
PSR 1 is working fine however.
This patchset introduces a new quirk to disable PSR 2 specifically on known
buggy devices and applies it to the Tongfang PHxTxX1 and PHxTQx1 barebones.
Signed-off-by: Werner Sembach
Cc:
This adds the possibility to disable PSR 2 explicitly using the intel
quirk table for devices where PSR 2 is borked, but PSR 1 works fine.
Signed-off-by: Werner Sembach
Cc:
---
drivers/gpu/drm/i915/display/intel_psr.c| 4 +++-
drivers/gpu/drm/i915/display/intel_quirks.c | 6 ++
drivers
eeded.
Cc: Werner Sembach
Signed-off-by: Hans de Goede
Tested and can confirm: The quirks are no longer needed with this Patchset.
Tested-by: Werner Sembach
Kind Regards,
Werner Sembach
---
drivers/acpi/video_detect.c | 75 -
1 file changed, 75
zation? This assumes that besides the initial value
being unused it's still a sane default
for all drivers.
Kind Regards,
Werner Sembach
Am 30.06.21 um 17:10 schrieb Werner Sembach:
This commit implements the "Broadcast RGB" drm property for the AMD GPU
driver.
Signed-off-by: Werner Sembach
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 14 +++---
.../amd/display/amdgpu_dm/amdgpu_dm_mst_types
Am 01.07.21 um 13:30 schrieb Werner Sembach:
Am 01.07.21 um 09:42 schrieb Pekka Paalanen:
On Wed, 30 Jun 2021 11:42:10 +0200
Werner Sembach wrote:
Am 30.06.21 um 10:21 schrieb Pekka Paalanen:
On Tue, 29 Jun 2021 13:02:05 +0200
Werner Sembach wrote:
Am 28.06.21 um 19:03 schrieb Werner
Am 06.07.21 um 09:09 schrieb Pekka Paalanen:
On Mon, 5 Jul 2021 17:49:42 +0200
Werner Sembach wrote:
Am 01.07.21 um 15:24 schrieb Pekka Paalanen:
On Thu, 1 Jul 2021 14:50:13 +0200
Werner Sembach wrote:
Am 01.07.21 um 10:07 schrieb Pekka Paalanen:
On Wed, 30 Jun 2021 11:20:18 +0200
Am 01.07.21 um 15:24 schrieb Pekka Paalanen:
> On Thu, 1 Jul 2021 14:50:13 +0200
> Werner Sembach wrote:
>
>> Am 01.07.21 um 10:07 schrieb Pekka Paalanen:
>>
>>> On Wed, 30 Jun 2021 11:20:18 +0200
>>> Werner Sembach wrote:
>>>
>>>>
Am 01.07.21 um 10:07 schrieb Pekka Paalanen:
> On Wed, 30 Jun 2021 11:20:18 +0200
> Werner Sembach wrote:
>
>> Am 30.06.21 um 10:41 schrieb Pekka Paalanen:
>>
>>> On Tue, 29 Jun 2021 13:39:18 +0200
>>> Werner Sembach wrote:
>>>
>>>>
Am 01.07.21 um 09:42 schrieb Pekka Paalanen:
> On Wed, 30 Jun 2021 11:42:10 +0200
> Werner Sembach wrote:
>
>> Am 30.06.21 um 10:21 schrieb Pekka Paalanen:
>>> On Tue, 29 Jun 2021 13:02:05 +0200
>>> Werner Sembach wrote:
>>>
>>>> A
This commit implements the "preferred color format" drm property for the
Intel GPU driver.
Signed-off-by: Werner Sembach
---
drivers/gpu/drm/i915/display/intel_dp.c | 7 ++-
drivers/gpu/drm/i915/display/intel_dp_mst.c | 5 +
drivers/gpu/drm/i915/display/intel_hdmi.c | 6
he monitor and what the default behaviour of the used driver is. This
property helps eliminating the guessing at this point.
In the future, automatic color calibration for screens might also depend on
this information being available.
Signed-off-by: Werner Sembach
---
drivers/gpu/drm/drm_connec
bandwidth heavy ycbcr422 and ycbcr420 formats
for a signal that is less deceptible to interference.
In the future, automatic color calibration for screens might also depend on
this option being available.
Signed-off-by: Werner Sembach
---
drivers/gpu/drm/drm_atomic_helper.c | 4 +++
drive
Change from the i915 specific "Broadcast RGB" drm property implementation
to the general one.
This commit delete all traces of the former "Broadcast RGB" implementation
and add a new one using the new driver agnoistic functions an variables.
Signed-off-by: Werner Sembach
e a manual overwrite is required to not have
washed out colors or lose details in very dark or bright scenes.
Signed-off-by: Werner Sembach
---
drivers/gpu/drm/drm_atomic_helper.c | 4 +++
drivers/gpu/drm/drm_atomic_uapi.c | 4 +++
drivers/gpu/drm/drm_connector.c | 46
This commit implements the "Broadcast RGB" drm property for the AMD GPU
driver.
Signed-off-by: Werner Sembach
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 14 +++---
.../amd/display/amdgpu_dm/amdgpu_dm_mst_types.c| 4
2 files changed, 15 insertions(+), 3
This commit implements the "active color range" drm property for the Intel
GPU driver.
Signed-off-by: Werner Sembach
---
drivers/gpu/drm/i915/display/intel_display.c | 7 +++
drivers/gpu/drm/i915/display/intel_dp.c | 1 +
drivers/gpu/drm/i915/display/intel_dp_mst.c | 5
This commit implements the "active color format" drm property for the AMD
GPU driver.
Signed-off-by: Werner Sembach
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 29 +--
.../display/amdgpu_dm/amdgpu_dm_mst_types.c | 4 +++
2 files changed, 31 insertions(+), 2
This commit implements the "active color range" drm property for the AMD
GPU driver.
Signed-off-by: Werner Sembach
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 33 +++
.../display/amdgpu_dm/amdgpu_dm_mst_types.c | 4 +++
2 files changed, 37 insertions(+)
di
1 - 100 of 231 matches
Mail list logo
