Matthew,
Am 07.03.2012 16:21, schrieb Matthew Garrett:
This is wrong. Since the GHID method returns an arbitrary
vendor-specific value, you should just make sure that there's
appropriate keymap remapping support and then provide a udev fragment
that does the appropriate GHID->keycode assignment. Also, you really do
need to report this as KEY_CDEJECT - it's not acceptable to require an
acpid script.
I had a look at the driver this morning. Just for testing purposes I
changed it in a way that it sends KEY_EJECTCD codes over the
input_report_key()-function, but this just works when I also have
set the KEY_EJECTCD bit with set_bit() before.
This brings me to the point, how I need to set the bits in that array
when the driver is loaded? Setting it with the "0x01" that the GHID
method returns is of no use, on the other hand I can replace the keymap
with /lib/udev/keymap, but that probably doesn't affect the bits in this
array.
The easiest (and maybe possible because BIOS development is just around
the corner here) would be to change the ACPI code so that GHID returns
the KEY_EJECTCD already, then it works out of the box, but the open
question is if this change will lead do regressions in the already
existing Windows driver.
Another idea: Making the quickstart driver aware of common HIDs like the
ODDE in my case and creating a correct keymap during driver
initalization. Then there is no need to remap GHID results to keycodes
via /lib/udev/keymap. What do you think of this idea?
Regards
Rainer
--
Dipl.-Inf. (FH) Rainer Koenig
Project Manager Linux Business Clients
Dept. TSP WPS R&D SW OSE
Fujitsu Technology Solutions
Bürgermeister-Ullrich-Str. 100
86199 Augsburg
Germany
Telephone: +49-821-804-3321
Telefax: +49-821-804-2131
Mail: mailto:Rainer.Koenig@xxxxxxxxxxxxxx
Internet ts.fujitsu.com
Company Details ts.fujitsu.com/imprint.html
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
