[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZdeDD9u965bM+CCc@duo.ucw.cz>
Date: Thu, 22 Feb 2024 18:23:27 +0100
From: Pavel Machek <pavel@....cz>
To: Hans de Goede <hdegoede@...hat.com>
Cc: Werner Sembach <wse@...edocomputers.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!
> > 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 to be a bit too
> generic.
Exactly.
> Given that these devices are all different in various ways
> and that we only want this for devices which cannot be accessed
> from userspace directly (so a limit set of devices) I really
> think that just doing custom ioctls per vendor is best.
I don't think that's good idea in the long term. Kernel should provide
hardware abstraction, so that userspace does not need to know about
hardware. Obviously there are exceptions, but this should not be one
of those.
BR,
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