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
- Prev by Date: Re: [OOPS] amrestore dies in kmem_cache_free 2.6.16.18 - cannot restore backups!
- Next by Date: Re: [SCRIPT] chomp: trim trailing whitespace
- Previous by thread: gcc-4.1.1/kernel 2.6.16.18 - miscompiled external module (old parameter not found)
- Next by thread: section mismatches in atyfb and macmodes
- Index(es):
 |