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!
> > 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 suggesting Hans. It's just that you don't
Hi!
So... I got two gaming keyboards. One is totally unusable (and it
looks LEDs are not controllable from the host), and the second one is
.. HyperX Elite RGB. Needs 2 USB connections, very buggy, probably
needs repair, and I'd not recomend it to anyone. But that one seems to
be usable for RGB ke
On Mon, Mar 25, 2024 at 07:38:46PM +0100, Miguel Ojeda wrote:
> On Mon, Mar 25, 2024 at 3:25 PM Hans de Goede wrote:
> >
> > +Cc: Bentiss, Jiri
>
> Cc'ing Andy and Geert as well who recently became the
> maintainers/reviewers of auxdisplay, in case they are interested in
> these threads (one of t
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 c
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 custom protocol in
Hi,
On 3/26/24 4:39 PM, Benjamin Tissoires wrote:
> 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 ca
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 kn
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 known
> > > > protocol and can be cros
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
On Mon, Mar 25, 2024 at 3:25 PM Hans de Goede wrote:
>
> +Cc: Bentiss, Jiri
Cc'ing Andy and Geert as well who recently became the
maintainers/reviewers of auxdisplay, in case they are interested in
these threads (one of the initial solutions discussed in a past thread
a while ago was to extend au
Hi Werner,
On 3/25/24 5:48 PM, Werner Sembach wrote:
> 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 2
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 feedbac
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.
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. And at least this thread is a
+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. And at least this thread is a
>> good comprehesive reference for the future ^^.
>>
>> To
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 feedback. And at least this thread
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 ^^.
To
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 RGB
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 sing
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 fina
Hi Werner,
Sorry for the late reply.
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 final UAPI for complex RGB lighting devices:
>
> - By
Hi
Am 22.02.24 um 18:38 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 /*
On Thu, 22 Feb 2024 18:38:16 +0100
Pavel Machek wrote:
> 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
> > > >
> > >
> > > >
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 /
Hi!
> For all these reasons the display analogy really is a bit fit for these
> keyboards
> we tried to come up with a universal coordinate system for these at the
> beginning
> of the thread and we failed ...
I quite liked the coordinate system proposal. I can propose this:
Vendor maps the ke
Hi!
> > To be honest, I think the kernel shouldn't include too much high-level
> > complexity. If there is a desire to implement a generic display device on
> > top of the RGB device, this should be a configurable service running in
> > user space. The kernel should provide an interface to expo
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 /* one o
Hi!
> > Yeah, so ... this is not a interface. This is a backdoor to pass
> > arbitrary data. That's not going to fly.
>
> Pavel, Note the data will be interpreted by a kernel driver and
> not passed directly to the hw.
Yes, still not flying :-).
> With that said I tend to agree that this seems
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 singular /sys/class/leds/* entry that treats the device
as if it was a sin
This certainly is the most KISS approach. This proposal
in essence is just an arbitrary command multiplexer /
demultiplexer and ioctls already are exactly that.
With the added advantage of being able to directly use
pass the vendor-cmd-specific struct to the ioctl instead
of having to first embed
Hi,
On 2/22/24 12:38, Gregor Riepl wrote:
>> This certainly is the most KISS approach. This proposal
>> in essence is just an arbitrary command multiplexer /
>> demultiplexer and ioctls already are exactly that.
>>
>> With the added advantage of being able to directly use
>> pass the vendor-cmd-sp
Hi,
On 2/21/24 23:17, Pavel Machek wrote:
> 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 comman
On Wed, 21 Feb 2024 23:17:52 +0100
Pavel Machek wrote:
> 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:
> > >
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 /* one of supported_commands */
> >
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:
>{
>
e up witrh this rough updated draft for the new uapi:
>
> Future handling of complex RGB devices on Linux:
>
> Optional: Provide a basic leds-subsystem driver:
> - The whole device is treated as a singular RGB led in the current leds
> uapi
> - Backwards compatib
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
39 matches
Mail list logo
