[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZdZ2kMASawJ9wdZj@duo.ucw.cz>
Date: Wed, 21 Feb 2024 23:17:52 +0100
From: Pavel Machek <pavel@....cz>
To: Werner Sembach <wse@...edocomputers.com>
Cc: Hans de Goede <hdegoede@...hat.com>, Lee Jones <lee@...nel.org>,
jikos@...nel.org, linux-kernel@...r.kernel.org,
Jelle van der Waa <jelle@...aa.nl>,
Miguel Ojeda <miguel.ojeda.sandonis@...il.com>,
"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
linux-input@...r.kernel.org, ojeda@...nel.org,
linux-leds@...r.kernel.org
Subject: Re: Future handling of complex RGB devices on Linux v2
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 */
> > union data
> > {
> > char raw[3072],
> > {
> > <input struct for command 0>
> > },
Yeah, so ... this is not a interface. This is a backdoor to pass
arbitrary data. That's not going to fly.
For keyboards, we don't need complete new interface; we reasonable
extensions over existing display APIs -- keyboards are clearly 2D.
Best regards,
Pavel
--
People of Russia, stop Putin before his war on Ukraine escalates.
Download attachment "signature.asc" of type "application/pgp-signature" (196 bytes)
Powered by blists - more mailing lists