tracking Fn key events

[Christian Trefzer <ctrefzer@gmx.de>]

Hi all,

could it be possible to track the Fn key on laptops in a generic way, so
I might notify a driver to read back register values, ie. on key
release? I'd like to do this in the driver itself, because the issues at
hand are very specific to the NeoMagic framebuffer driver implementation
and its interaction with the hardware.

The clean alternative of course would be sysfs attributes, but so far I
could not find ways to tap Fn key events from user space. OTOH, it seems
strange to me that one might need some sort of daemon running to render
a display driver functional. So here lies my dilemma in the first place:
the beast should be self-contained IMHO, but more than a sh*tload of
hacks in the end.


This is what I intend to achieve: the neofb driver has issues with
reading and writing to registers, such as the backlight status bits.

Until I made the driver re-read the register values in question, the
thing used to restore previous display configuration (combination of
internal/external) upon unblanking the display through the usual console
blanking mechanisms. Now the driver stores the values read during screen
blanking, avoiding the reset to whichever configuration was active
during neofb initialization.

Now the following problem arises: once I shut the LID, the hardware or
firmware turns off the backlight, which is somewhat sensible. A few
minutes later, the console code decides it is time to blank the screen,
reading back the (now bogus) values. Once the LID is re-opened, the
display comes back to life, but after the first key stroke the console
is "un-blanked" and the backlight set to "off". The problem can be
solved by shutting and opening the LID once more, abusing whatever
mechanism is designed into the hardware/firmware combo.

The quick and dirty fix I tried was to use acpid for handling LID events
such that it should disable/enable console blanking via setterm calls.
Needless to say, this did not work out as expected and would be not
quite acceptable if the driver is expected to be self-contained.

My favourite solution would be wiretapping the Fn key, sending the neofb
driver an event whenever it is _released_. After a minimal timeout, the
register values should have changed underneath and neofb could read back
the values, thus properly accounting for any changes therein.

Any hints appreciated!

Kind regards,
Chris

Attachment: pgpFO39E8SXmy.pgp
Description: PGP signature