Date: Wed, 7 May 2014 08:52:30 -0700 From: Adrian Chadd <adrian@freebsd.org> To: =?UTF-8?B?WMSrY8Oy?= <xico@atelo.org> Cc: "freebsd-acpi@freebsd.org" <freebsd-acpi@freebsd.org>, Rui Paulo <rpaulo@freebsd.org> Subject: Re: Emitting keyboard events Message-ID: <CAJ-Vmon6o37HYBC2KXbrXatAdv9e_%2BppEcoqZheRNxj2wUPHGA@mail.gmail.com> In-Reply-To: <20140507154607.GA1826@coyotlan.Tlalpan> References: <20140501205706.GA6007@coyotlan.Tlalpan> <CAJ-VmomkgZ39-unFA-rcCtY8YgJpTXpuGtVn%2Bbwv4CQW4xx=Kw@mail.gmail.com> <20140507135117.GL1451@e-new.0x20.net> <20140507154607.GA1826@coyotlan.Tlalpan>
next in thread | previous in thread | raw e-mail | index | archive | help
On 7 May 2014 08:46, X=C4=ABc=C3=B2 <xico@atelo.org> wrote: > On Wed, May 07, 2014 at 03:51:17PM +0200, Lars Engels wrote: >> IIRC Rui (CC'ed) did some work on implementing new ACPI key events in >> acpi_asus for the first EeePC. > > Looking around the acpi drivers, some hard-encode actions associated to > the events (like brightness control), some emit messages for devd (like > sound control for the asus), and most mix the two options. > > Emitting devd events is both easy and highly user configurable. But it > still does not solve the problem of reinjecting the special keys as > generic keyboard events, for instance to let the user configure them > through xorg. Writing a virtual keyboard in each acpi driver seems a lot > of duplication, and maybe too heavy. IMHO acpi drivers should just emit > information to be caught by devd. Maybe with a single format, so that a > shared other component can listen to them and reinject them as generic > keyboard events. Indeed. Hack it up, send through patches. :) -a
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-Vmon6o37HYBC2KXbrXatAdv9e_%2BppEcoqZheRNxj2wUPHGA>