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
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
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
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
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
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
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
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:
>{
>
13 matches
Mail list logo
