Re: [ibm-acpi-devel] [PATCH] ACPI: thinkpad-acpi: add thinkpad keys to input.h
On 5/29/07, Henrique de Moraes Holschuh [EMAIL PROTECTED] wrote: On Mon, 28 May 2007, Dmitry Torokhov wrote: On Sunday 27 May 2007 08:15, Henrique de Moraes Holschuh wrote: On Sat, 26 May 2007, Dmitry Torokhov wrote: I am unconvinced that we need new keycodes. Isn't there a better default keycodes for these keys? You mentioned that fn+f5 controls radio on many thinkpads, why don't you use KEY_WLAN in your keymap? No can do the KEY-WLAN thing, sorry. I *don't* have a way to know, unless I add a model-specific map table to the kernel, and I have been told by numerous people to don't even try, unless it is for quirks, etc. Why not? It thinkpad-acpi is a box-specific driver and you could try to setup proper keymap depending on models. We do that in wistron_btns and it doers not even need alot of memory (keymaps and dmi data is marked __initdata and is discarded). Well, I will try, let's see if ACPI upstream will take it after I tell them it was decided to be the best approach by the input layer people. Yes, it can be __initdata, so it should not cause any drawbacks. But I will still need to add keys, and I still think that a bunch of 32 or so HOSTSPECIFIC keys is a very very good idea to have, *even* if I add some model specific knowledge and already remap a few of the hot key keyboard to less generic events where possible. I think that adding anything like HOSTSPECIFIC is a failure on our part. That means that you need to make programs out there aware of multiple hosts and their usage. You can't just say that you going to teach X and the rest will use X facilities because there is world outside of X. Programs like HAL, network management (rfkill) other daemons getting input directly from /dev/input/eventX will have to be made aware. This is not good. I really don't like KEY_FN_F1..KEY_FN_BACKSPACE either. What are they supposed to do? Just being an unique value to be mapped onto something useful? But why not use that useful keycode to begin with? I'd rather leave the keys unmapped and rely on initsripts (possibly with help from distributions vendors) to load proper keymap then add something that must be retranslated over and over again. Really, what are we to do with that input.h scancode map? It *IS* supposed to be absolute, i.e. one is not supposed to reuse keys in there if the functionality *or* the generic description is not an exact match. Are there any markings on those keys? Only a few of them. And the ones I wanted to add are *not* marked in most models :-) The markings change a bit from model to model, and we have a *very* incomplete list of those... Well, what kind of functions you would like them to have? You, as a maintainer, can chose defaults. Since you (well, not you, the driver) provide a way for a user to adjust keymap there should be no problem even if someone does not like the values you chose. Having sensible defaults is a good thing, otherwise many people will not even know that they have these separate keys. Alternatively, if you let me add keys, I will need a few of them, and they are also generic (not necessarily thinkpad-specific). Stuff like: KEY_FN_BACKSPACE, KEY_VENDORHOMEPAGE, And what are their intended functions would be? How KEY_VENDORHOMEPAGE is different from KEY_HOMEPAGE? -- Dmitry - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ ibm-acpi-devel mailing list ibm-acpi-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel
Re: [ibm-acpi-devel] [PATCH] ACPI: thinkpad-acpi: add thinkpad keys to input.h
On Wed, May 30, 2007 at 09:57:11AM -0400, Dmitry Torokhov wrote: I really don't like KEY_FN_F1..KEY_FN_BACKSPACE either. What are they supposed to do? Just being an unique value to be mapped onto something useful? But why not use that useful keycode to begin with? We've already got KEY_PROG* - is this not the sort of situation they're for? (ie, keys that aren't mapped to a specific purpose but would be potentially useful to userspace at the per-user level) I'd rather leave the keys unmapped and rely on initsripts (possibly with help from distributions vendors) to load proper keymap then add something that must be retranslated over and over again. Changing the keymap is a privileged operation, so sending /some/ sort of keycode by default would probably be good. Well, what kind of functions you would like them to have? You, as a maintainer, can chose defaults. Since you (well, not you, the driver) provide a way for a user to adjust keymap there should be no problem even if someone does not like the values you chose. Having sensible defaults is a good thing, otherwise many people will not even know that they have these separate keys. Some of the Thinkpad keys send events even without there being any label, so I don't think there's a sane default other than leaving it up to the user. On the other hand, I'm not especially keen on sending literals like FN_BACKSPACE - it's hugely special-cased. -- Matthew Garrett | [EMAIL PROTECTED] - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ ibm-acpi-devel mailing list ibm-acpi-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel
Re: [ibm-acpi-devel] [PATCH] ACPI: thinkpad-acpi: add thinkpad keys to input.h
On Wed, May 30, 2007 at 10:18:17AM -0400, Dmitry Torokhov wrote: Hi Matthew, We've already got KEY_PROG* - is this not the sort of situation they're for? (ie, keys that aren't mapped to a specific purpose but would be potentially useful to userspace at the per-user level) Right. These are they keys we have no idea how to use these, leave it to the user. Do we really need more of these? We have quite a few codes that might be useful. I just don't want to keep adding a new input keycode every time we encounter an unmarked key somewhere. Sorry, I wasn't clear - I was thinking that they should just be used for this case, rather than that more of them be added. Changing the keymap is a privileged operation, so sending /some/ sort of keycode by default would probably be good. It's up to the security policy on a particular box. One could change /dev/input/evdev ownership to the user currently logged on physical console. Most users will be logged into X, so it's the X keymap that's the most interesting one. X tools know how to remap the X keymap without requiring any sort of special privileges, so all we need is for the keycode to generate /something/. I think KEY_PROG* would make the most sense, and that's what we've adopted in Ubuntu. -- Matthew Garrett | [EMAIL PROTECTED] - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ ibm-acpi-devel mailing list ibm-acpi-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel
Re: [ibm-acpi-devel] [PATCH] ACPI: thinkpad-acpi: add thinkpad keys to input.h
On Wed, May 30, 2007 at 10:31:35AM -0400, Dmitry Torokhov wrote: Not all world is X :) Actually few of FN keys, like KEY_WLAN, KEY_SLEEP, etc should be handled not [only] by X but by other layers. I agree - the ones that have a defined function should certainly be set to sensible defaults, but I think the sensible default for a key without a defined function is Key of undefined function (like KEY_PROG*), not Key which doesn't generate a keycode :) -- Matthew Garrett | [EMAIL PROTECTED] - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ ibm-acpi-devel mailing list ibm-acpi-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel
Re: [ibm-acpi-devel] [PATCH] ACPI: thinkpad-acpi: add thinkpad keys to input.h
On Wed, 30 May 2007, Dmitry Torokhov wrote: On 5/30/07, Matthew Garrett [EMAIL PROTECTED] wrote: We've already got KEY_PROG* - is this not the sort of situation they're for? (ie, keys that aren't mapped to a specific purpose but would be potentially useful to userspace at the per-user level) Right. These are they keys we have no idea how to use these, leave it to the user. Do we really need more of these? We have quite a few Drat, I didn't know of those, otherwise I would not have asked for KEY_HOSTSPECIFIC_*. Thanks for the hint, Matthew! But there are too few KEY_PROG symbols. I'd need more than four of them for the entire set of thinkpad hot keys (including nvram-based ones). codes that might be useful. I just don't want to keep adding a new input keycode every time we encounter an unmarked key somewhere. A big enough set of KEY_PROG* would fix this. It is basically my argument for KEY_HOSTSPECIFIC, only that it has a different name, and that we already have four of them. Well, what kind of functions you would like them to have? You, as a maintainer, can chose defaults. Since you (well, not you, the driver) provide a way for a user to adjust keymap there should be no problem even if someone does not like the values you chose. Having sensible defaults is a good thing, otherwise many people will not even know that they have these separate keys. Some of the Thinkpad keys send events even without there being any label, so I don't think there's a sane default other than leaving it up to the user. On the other hand, I'm not especially keen on sending literals like FN_BACKSPACE - it's hugely special-cased. Well, I'd like to have a keycode I could use so that I have it working out-of-the-box. It can be KEY_PROG*, if there are enough of them (can I add more?). Or it will be something with a specific function, when I know what the marking on the key is. But really, not sending a keycode at all is non-optimal. And using a keycode that should be for something else (say, KEY_F13) is just wrong. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ ibm-acpi-devel mailing list ibm-acpi-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel
Re: [ibm-acpi-devel] [PATCH] ACPI: thinkpad-acpi: add thinkpad keys to input.h
On Wed, 30 May 2007, Dmitry Torokhov wrote: On 5/29/07, Henrique de Moraes Holschuh [EMAIL PROTECTED] wrote: But I will still need to add keys, and I still think that a bunch of 32 or so HOSTSPECIFIC keys is a very very good idea to have, *even* if I add some model specific knowledge and already remap a few of the hot key keyboard to less generic events where possible. I think that adding anything like HOSTSPECIFIC is a failure on our part. That means that you need to make programs out there aware of Well, you have to choose one of three possibilities for an unlabelled key: 1. Generate SOMETHING that has an undefined meaning or function, but which is unique for that keyboard (KEY_PROG/KEY_HOSTSPECIFIC) 2. Generate SOMETHING that has a non-specific function, but a well defined meaning (KEY_FN_F1) 3. Do nothing. I *REALLY* do not like (3), and so far I have not seen a single good technical reason to go with it. From the technically sound ones, you need to either have the keycodes you need for (2) (i.e. KEY_FN_BACKSPACE), or a big enough set of keycodes to use (1) (i.e. KEY_PROG5..KEY_PROGn, where n should probably be at least 8). I really don't like KEY_FN_F1..KEY_FN_BACKSPACE either. What are they supposed to do? Just being an unique value to be mapped onto something useful? But why not use that useful keycode to begin with? Yes, just an unique value to be mapped onto something useful, by something in userspace. Just like KEY_PROG, actually. One can't use a useful keycode for two reasons: 1. Because the key has no set function (it is unmarked) 2. Because it has, or could have, a set function, but we have no clue which is it. I'd rather leave the keys unmapped and rely on initsripts (possibly with help from distributions vendors) to load proper keymap then add something that must be retranslated over and over again. I don't. I can live with it, of course, but if we are going to go that way, what IS the excuse for a big lot of the keys already in input.h? We have been adding the unique keycodes and functional keycodes because it is *useful*. Again, let me remind you that I have nothing against using functional keycodes (KEY_HOMEPAGE, KEY_WLAN) when we know the key is actually that, and that all I am asking for is some non-wrong keycode to use when we don't (so that I don't use KEY_F13 for KEY_FN_INSERT, for example). Heck, I even proposed to write a patch to do away with most of the KEY_FN and make them into KEY_HOSTSPECIFIC (now it would be KEY_PROG, of course), which would stop wasting keymap codepoints for stuff that has no set functions, anyway. Of course, if I needed keys for a specific function, I'd be asking for them instead, but I am not there yet. And what are their intended functions would be? How KEY_VENDORHOMEPAGE is different from KEY_HOMEPAGE? KEY_VENDORHOMEPAGE is exactly that. It is marked with the vendor's name. KEY_HOMEPAGE has a defined function inherited from that other O.S. which is to open up the default browser on the default homepage. I can easily see both keys existing on a system. As for stuff like KEY_FN_BACKSPACE, well, I don't really care, as long as I have *something* unique and not incorrect to use. But if we are not going to add extra KEY_FN_ keycodes, why don't we just convert them all to KEY_PROG, so that they can be useful to all and not just to people who have FN_whatever keys? -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ ibm-acpi-devel mailing list ibm-acpi-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel
Re: [ibm-acpi-devel] [PATCH] ACPI: thinkpad-acpi: add thinkpad keys to input.h
On 5/30/07, Henrique de Moraes Holschuh [EMAIL PROTECTED] wrote: On Wed, 30 May 2007, Dmitry Torokhov wrote: On 5/29/07, Henrique de Moraes Holschuh [EMAIL PROTECTED] wrote: But I will still need to add keys, and I still think that a bunch of 32 or so HOSTSPECIFIC keys is a very very good idea to have, *even* if I add some model specific knowledge and already remap a few of the hot key keyboard to less generic events where possible. I think that adding anything like HOSTSPECIFIC is a failure on our part. That means that you need to make programs out there aware of Well, you have to choose one of three possibilities for an unlabelled key: 1. Generate SOMETHING that has an undefined meaning or function, but which is unique for that keyboard (KEY_PROG/KEY_HOSTSPECIFIC) How do you guarantee that KEY_PROG* is unique for the keyboard? What do you do if you have 2 devices generating KEY_PROG1? 2. Generate SOMETHING that has a non-specific function, but a well defined meaning (KEY_FN_F1) And we have plenty of those. 3. Do nothing. Well, probably not nothing. Map it to KEY_UNKNOWN and have userspace listen to such events and inform user when it presses such a key that such and such happened and tell him how to map it to something useful. I *REALLY* do not like (3), and so far I have not seen a single good technical reason to go with it. Reasons: do not require expaning current keymap preserving space for more useful keycodes. From the technically sound ones, you need to either have the keycodes you need for (2) (i.e. KEY_FN_BACKSPACE), or a big enough set of keycodes to use (1) (i.e. KEY_PROG5..KEY_PROGn, where n should probably be at least 8). Why 8? Why not 16? Or 32 just to make sure? I really don't like KEY_FN_F1..KEY_FN_BACKSPACE either. What are they supposed to do? Just being an unique value to be mapped onto something useful? But why not use that useful keycode to begin with? Yes, just an unique value to be mapped onto something useful, by something in userspace. Just like KEY_PROG, actually. In _every_ program that gets events directly? One can't use a useful keycode for two reasons: 1. Because the key has no set function (it is unmarked) 2. Because it has, or could have, a set function, but we have no clue which is it. KEY_UNKNOWN then. I'd rather leave the keys unmapped and rely on initsripts (possibly with help from distributions vendors) to load proper keymap then add something that must be retranslated over and over again. I don't. I can live with it, of course, but if we are going to go that way, what IS the excuse for a big lot of the keys already in input.h? We have been adding the unique keycodes and functional keycodes because it is *useful*. Because they most of them describe an expected _action_ that would happend after keypress. [...skipped...] And what are their intended functions would be? How KEY_VENDORHOMEPAGE is different from KEY_HOMEPAGE? KEY_VENDORHOMEPAGE is exactly that. It is marked with the vendor's name. KEY_HOMEPAGE has a defined function inherited from that other O.S. which is to open up the default browser on the default homepage. I can easily see both keys existing on a system. OK, right now we have: KEY_WWW KEY_VENDOR KEY_HOMEPAGE defines in input.h. Are you sayign that none of these would suit? As for stuff like KEY_FN_BACKSPACE, well, I don't really care, as long as I have *something* unique and not incorrect to use. But if we are not going to add extra KEY_FN_ keycodes, why don't we just convert them all to KEY_PROG, so that they can be useful to all and not just to people who have FN_whatever keys? We could add aliases if you really want... Can you tell me on _your_ thinkpad what markings you have? I mean there should be a common pattern on thinkpads and the rest may be guessed (you mentioned that FN-F5 is used to turn off radio quite often so if thinkpad driver detects radio switch it makes sence to just go ahead and mark FN-F5 as KEY_WLAN, doesn't it?) -- Dmitry - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ ibm-acpi-devel mailing list ibm-acpi-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel
Re: [ibm-acpi-devel] [PATCH] ACPI: thinkpad-acpi: add thinkpad keys to input.h
On Wed, 30 May 2007, Dmitry Torokhov wrote: 1. Generate SOMETHING that has an undefined meaning or function, but which is unique for that keyboard (KEY_PROG/KEY_HOSTSPECIFIC) How do you guarantee that KEY_PROG* is unique for the keyboard? What do you do if you have 2 devices generating KEY_PROG1? It is trivial to guarantee that KEY_PROG is unique for a single input device (keyboard), but it certainly won't work across multiple devices. Userspace has to know what kind of input device it is talking to to map them to something, but since the input layer already provides this information, I was not going to raise a fuss about it. I figure it is the price of not increasing even more the keycode table. 2. Generate SOMETHING that has a non-specific function, but a well defined meaning (KEY_FN_F1) And we have plenty of those. Yeah, but not enough of them or I would not have asked for five more :-) 3. Do nothing. Well, probably not nothing. Map it to KEY_UNKNOWN and have userspace listen to such events and inform user when it presses such a key that such and such happened and tell him how to map it to something useful. Not optimal, but certainly much better than do nothing. I will go with this one, if I can't have my extra FN keys or PROG keys. That said, how is one to know which hardware key was translated to KEY_UNKNOWN, so that he can inform the user to remap that key? Should I send another event together with KEY_UNKNOWN that has the raw keycode? Which one? I *REALLY* do not like (3), and so far I have not seen a single good technical reason to go with it. Reasons: do not require expaning current keymap preserving space for more useful keycodes. We should either reclaim space then (remove all of KEY_FN_* and make them KEY_PROG* generic stuff), or double the entire keycode space (add one bit to KEY_MAX) so that new keycodes can be added for a while. Declaring a keycode crunch on drivers when one gets close to exausting each bit of KEY_MAX is not a solution IMHO. From the technically sound ones, you need to either have the keycodes you need for (2) (i.e. KEY_FN_BACKSPACE), or a big enough set of keycodes to use (1) (i.e. KEY_PROG5..KEY_PROGn, where n should probably be at least 8). Why 8? Why not 16? Or 32 just to make sure? Eight is a bare minimum (and enough for my needs if the KEY_FN already there don't go away :p), but I already told you that if it were up to me, I'd convert all of FN_ to such codes, and cover 0x1d0 to 0x1ef with them, which gives us 32 generic codes. We would have 36 KEY_PROG then, which hopefully would be enough for a while. I really don't like KEY_FN_F1..KEY_FN_BACKSPACE either. What are they supposed to do? Just being an unique value to be mapped onto something useful? But why not use that useful keycode to begin with? Yes, just an unique value to be mapped onto something useful, by something in userspace. Just like KEY_PROG, actually. In _every_ program that gets events directly? Yes. It is not nearly as nice as functional key codes (like KEY_WLAN), but it is better than KEY_UNKONWN or wrong keys. Of course, if you *know* a key's function, you use that. One can't use a useful keycode for two reasons: 1. Because the key has no set function (it is unmarked) 2. Because it has, or could have, a set function, but we have no clue which is it. KEY_UNKNOWN then. KEY_UNKNOWN requires that userspace remap it for it to be usable. I'd rather leave the keys unmapped and rely on initsripts (possibly with help from distributions vendors) to load proper keymap then add something that must be retranslated over and over again. I don't. I can live with it, of course, but if we are going to go that way, what IS the excuse for a big lot of the keys already in input.h? We have been adding the unique keycodes and functional keycodes because it is *useful*. Because they most of them describe an expected _action_ that would happend after keypress. But why can't we get those that do NOT do that and are not around most keyboards to be completely generic, then? [...skipped...] And what are their intended functions would be? How KEY_VENDORHOMEPAGE is different from KEY_HOMEPAGE? KEY_VENDORHOMEPAGE is exactly that. It is marked with the vendor's name. KEY_HOMEPAGE has a defined function inherited from that other O.S. which is to open up the default browser on the default homepage. I can easily see both keys existing on a system. OK, right now we have: KEY_WWW KEY_VENDOR KEY_HOMEPAGE defines in input.h. Are you sayign that none of these would suit? KEY_VENDOR would work for me. I had not searched around for one yet, and I would have found it out before sending you a patch asking for KEY_VENDORHOMEPAGE. KEY_PROG, on the other hand, looked to me like an function (like program macro or whatever). As for stuff like KEY_FN_BACKSPACE, well, I don't really care, as long as I have
Re: [ibm-acpi-devel] [PATCH] ACPI: thinkpad-acpi: add thinkpad keys to input.h
On Wed, May 30, 2007 at 04:25:03PM -0400, Dmitry Torokhov wrote: Consider ejecting a CD tray. You have a laptop with a key that maked eject CD. Because it is a new laptop there are no proper mapping yet so some adjustments are needed. With your scenario the kernel emits KEY_PROG26. User has first to adjust X keymap to map KEY_PROG26 to EjectCD event (simplifying). Then he goes into text console only to find out that his curses-based CD player does not recognize that key and also needs to be adjusted. And so on. Finally all applications are made aware of KEY_PROG26 amd user is happy. Couple of weeks later he goes and buys an external keyboard and it turns out that eject CD there is actually KEY_PROG21 so he need to go through second round of mapping for all applications. Not only that but button with volume increase happens to generate KEY_PROG26. Now what? Now consider in-kernel remapping to functional scancdes that I propose: user says that that key should generate KEY_EJECTCD and it starts working in all appliations recognizing that event. Adding the second keyboard into mix does not mess up the first one. That makes absolute sense when a key has a defined function, but in the case we're discussing it doesn't. So, we have two choices: 1) Map it to a specific function system-wide (so a default of KEY_UNKNOWN is fine) 2) Map it to a specific function at the user level If the key doesn't have anything printed on it, there is no correct system-wide default. It's intrinsically a per-user preference. But for the user to be able to decide what the key does, it has to generate a keycode. Once it does that they can use one of the existing X applications to bind that to an X keysym and then everyone is happy. But for this to be possible a keycode has to be generated. We can either set this at boot time or in the kernel. The only argument for doing it at boot time is that userspace might have a better idea what the key should map to. However, in the case of a blank key, how is userspace going to have any more idea than the kernel does? The only sane default is something like KEY_PROG1. -- Matthew Garrett | [EMAIL PROTECTED] - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ ibm-acpi-devel mailing list ibm-acpi-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel
[ibm-acpi-devel] [PATCH] ACPI: thinkpad-acpi: do not use named sysfs groups
The initial version of the thinkpad-acpi sysfs interface (not yet released in any stable mainline kernel) made liberal use of named sysfs groups, in order to get the attributes more organized. This proved to be a really bad design decision. Maybe if attribute groups were as flexible as a real directory, and if binary attributes were not second-class citizens, the idea of subdirs and named groups would not have been so bad. This patch makes all the thinkpad-acpi sysfs groups anonymous (thus removing the subdirs), adds the former group names as a prefix (so that hotkey/enable becomes hotkey_enable for example), and updates the documentation. These changes will make the thinkpad-acpi sysfs ABI a lot easier to maintain. Signed-off-by: Henrique de Moraes Holschuh [EMAIL PROTECTED] --- It gets easier to apply if I actually get git to include the patch :) Sorry about that! Documentation/thinkpad-acpi.txt | 25 +++-- drivers/misc/thinkpad_acpi.c| 17 +++-- drivers/misc/thinkpad_acpi.h|6 -- 3 files changed, 18 insertions(+), 30 deletions(-) diff --git a/Documentation/thinkpad-acpi.txt b/Documentation/thinkpad-acpi.txt index 2d48033..9e6b94f 100644 --- a/Documentation/thinkpad-acpi.txt +++ b/Documentation/thinkpad-acpi.txt @@ -138,7 +138,7 @@ Hot keys procfs: /proc/acpi/ibm/hotkey -sysfs device attribute: hotkey/* +sysfs device attribute: hotkey_* Without this driver, only the Fn-F4 key (sleep button) generates an ACPI event. With the driver loaded, the hotkey feature enabled and the @@ -196,10 +196,7 @@ The following commands can be written to the /proc/acpi/ibm/hotkey file: sysfs notes: - The hot keys attributes are in a hotkey/ subdirectory off the - thinkpad device. - - bios_enabled: + hotkey_bios_enabled: Returns the status of the hot keys feature when thinkpad-acpi was loaded. Upon module unload, the hot key feature status will be restored to this value. @@ -207,19 +204,19 @@ sysfs notes: 0: hot keys were disabled 1: hot keys were enabled - bios_mask: + hotkey_bios_mask: Returns the hot keys mask when thinkpad-acpi was loaded. Upon module unload, the hot keys mask will be restored to this value. - enable: + hotkey_enable: Enables/disables the hot keys feature, and reports current status of the hot keys feature. 0: disables the hot keys feature / feature disabled 1: enables the hot keys feature / feature enabled - mask: + hotkey_mask: bit mask to enable ACPI event generation for each hot key (see above). Returns the current status of the hot keys mask, and allows one to modify it. @@ -229,7 +226,7 @@ Bluetooth - procfs: /proc/acpi/ibm/bluetooth -sysfs device attribute: bluetooth/enable +sysfs device attribute: bluetooth_enable This feature shows the presence and current state of a ThinkPad Bluetooth device in the internal ThinkPad CDC slot. @@ -244,7 +241,7 @@ If Bluetooth is installed, the following commands can be used: Sysfs notes: If the Bluetooth CDC card is installed, it can be enabled / - disabled through the bluetooth/enable thinkpad-acpi device + disabled through the bluetooth_enable thinkpad-acpi device attribute, and its current status can also be queried. enable: @@ -252,7 +249,7 @@ Sysfs notes: 1: enables Bluetooth / Bluetooth is enabled. Note: this interface will be probably be superseeded by the - generic rfkill class. + generic rfkill class, so it is NOT to be considered stable yet. Video output control -- /proc/acpi/ibm/video @@ -898,7 +895,7 @@ EXPERIMENTAL: WAN - procfs: /proc/acpi/ibm/wan -sysfs device attribute: wwan/enable +sysfs device attribute: wwan_enable This feature is marked EXPERIMENTAL because the implementation directly accesses hardware registers and may not work as expected. USE @@ -921,7 +918,7 @@ If the W-WAN card is installed, the following commands can be used: Sysfs notes: If the W-WAN card is installed, it can be enabled / - disabled through the wwan/enable thinkpad-acpi device + disabled through the wwan_enable thinkpad-acpi device attribute, and its current status can also be queried. enable: @@ -929,7 +926,7 @@ Sysfs notes: 1: enables WWAN card / WWAN card is enabled. Note: this interface will be probably be superseeded by the - generic rfkill class. + generic rfkill class, so it is NOT to be considered stable yet. Multiple Commands, Module Parameters diff --git a/drivers/misc/thinkpad_acpi.c
