gunna try this on a hp tx1000
Brought to you by:
miknix
Menu
▾
▴
Sir you driver is very timely! Only yesterday did I 'modify' the AML code in my bios to enable these buttons on non vista OS's. I now have a custom bios which I have flashed onto my laptop (luckily not breaking it in the process). Thus these buttons show up in windowz XP and in linux. Actually I am guessing that they show up in linux but I have no way to test this (ATM). I was trying to figure out how I would get these to work earlier today.
Google early and google often is my maxim from now :)
I will let you know any results I get.
Thanks
R
Hi raskery,
If you are only making changes to the ACPI AML code, you can do it in Linux without having to flash the BIOS.
Just extract the ACPI DSDT table:
$ cat /proc/acpi/dsdt > /tmp/dsdt.bin
Next disassemble it with the intel AML compiler.
$ iasl -d /tmp/dsdt.bin
/tmp/dsdt.dsl will be your AML code. Make your changes and compile it.
$ iasl -tc /tmp/dsdt.dsl
Copy the /tmp/dsdt.hex to /boot and in your kernel config
at "Power management options/ACPI/" select "Include custom DSDT".
Just change the path to /boot/dsdt.hex and rebuild your kernel.
The next time you boot Linux it should say:
"ACPI: Table DSDT replaced by host OS"
..and your acpi table changes should take effect.
At least you won't brick your laptop in case something goes wrong!
- - -
To test the driver just load it.. It should load without errors if devices are present and working.
You can see which buttons are supported by doing
$ cat /sys/devices/platform/hotstart/buttons
You can also power your computer using one of supported buttons. After booting linux and loading the module, the
pressed button name should be present on
$ cat /sys/devices/platform/hotstart/pressed_button
Good luck,
MiKNiX
Yeah I tried this last week. When I tried to recompile the kernel I got eror messages unrelated to the changes I made. Didn't have the time to go and fix those so I took the flashing bios route. I am more familiar with this as I have done it before to update bios stored firmware for things like sata drives. It has the added benefit of also making the buttons available in XP. The ASL code on the tx1000 switches things on only if it detects VISTA. So I can triple boot now with all features enabled.
BTW. This method is ok If one only sticks to one kernel. Fedora release kernels quite often and I would have to do this over every time the kernel is updated and as interesting as it is as a project I just don't want to have to do it again and again :).
OK driver loaded.
I triple boot XP, vista and linux. Putting it in the bios switches things on in XP as well (the bios has some aml code to say 'if I am not running Vista switch things off', pretty much excluding any other OS.
I can see all the buttons in the buttons file and I see a 'none' in pressed_buttons. I can't find the hardware which these buttons apply to. None of the buttons send events to those locations (none never changes!!). In /sys/bus/acpi/drivers/hotstart/driver I see links to PNP0C32:00 to PNP0C32:06 so the hotstart driver has found the acpi events. I am not testing with starting up the laptop with these buttons (as suspend and hibernate are flaky at the moment, but that is a different problem....)
Am I reading this wrong. Is pressed_button only populated when the machine is started from on of those buttons?
R
>> I can see all the buttons in the buttons file and I see a 'none' in pressed_buttons.
This is good news..
>> Am I reading this wrong. Is pressed_button only populated when the machine is started from on of those buttons?
Yes, pressed_button is the button you have pressed to turn on the laptop.
Did you read information on this project webpage? If so, I guess the information provided isn't much self explanatory. :\
If you are just trying to make your hotkeys working, devices under PNP0C32 aren't the ones you should look to..
I own a HP dv6535ep and hotkeys are working as a normal keyboard, I didn't inspect further since they are, heh, working..
lol, actually it was very well explained. I took a look at the source code and I see that the driver does not return the buffer according to the ACPI spec. Early code I know so not a problem. However this will probably be needed if it is going to go inot the kernel acpi driver.
I have done some testing with starting the machine using the hotstart buttons and they report fine. Do you think you can update the code to output something whilst the machine is running normally? My laptop only has two buttons setup to start the machine out of a possible seven so I can't test everything. I would throw some code at you but I don't know C.
The way windows does this is the bios writes to the WMI bios data and windows reads this and writes it to the registry so applications can access it. I am not sure how this would be done in the linux environment.
Perhaps the driver can write to file called 'startup-button' which would be the first value read from the devices at module start and then to pressed-button after that. This way a user space app can always find out how the machine was started (if there is a non - `none` value then it was started by a hotstart button) as this value would remain until the module was next reloaded (at the next reboot for example). Then whilst the machine was running the hotstart module could write to `pressed button`. Although it still isn't up to the acpi specs it would be great for testing.
Any thoughts on what would need to be done to get this into the kernel?? It would definately fix many issues from what I have read. Not all my buttons produce scancodes or are even presented to linux. Critically the `rotate screen button` which I can use to signal the nvidia driver to rotate the screen. My tablet PC would then work perfectly with linux and Vista gets fdisked into history :) actually getting this to work would pretty much make the HP tx1000 95% compatible with linux (still some suspend/hibernate issues and the fingerprint scanner is awaiting a fully functional driver, but *everything* else will work).
OK, I will horsetrade with you. If you can make the changes to get it to work during runtime I will write an installer script (and perhaps a daemon) and package it as an RPM for you :)
Thanks
Rehan
The code is using GHID so I guess it is using the WMI data (at least thats the way GHID seems to work in the ASL code on my laptop).
I was looking through the acpi_toshiba and the omnibook drivers documentation. The acpi_toshiba driver seems to create an entry under /proc/acpi. Perhaps this would be a better place for the hotstart driver. Maybe acpi/button/hotstart or something? If this was the case then a conf file could be created in etc/acpi/events for each button which would startup the relevant action. If the vendors use different button names then I guess this would need to be manually tweaked for each for different hardware. However acpid would handle the events generated by the driver. The hotkey part of the above drivers create a file in /proc/acpi when there is one or more events queued. The conf can then look for that file and take action when it is present.
Hope you don't mind these suggestions miknix, like I said I can't code in C otherwise I would have a go.
Regards
R
> lol, actually it was very well explained. I took a look at the source code and I see that the driver does not return the
> buffer according to the ACPI spec. Early code I know so not a problem. However this will probably be needed if it is
> going to go inot the kernel acpi driver
>> The Microsoft-defined GHID method indicates the desired function, or “role”, of the button, such as media, Internet, or calculator. This description is used to help associate the button with the correct application to launch. The GHID method returns a buffer that contains a value that indicates the button function. The manufacturer chooses the actual value, which can be mapped to the target application by using the Windows registry. The GHID method can return a BYTE, WORD, or DWORD [Direct App Launch MS paper]<<
Buffer values are manufacturer specific so I doubt where they can be helpful to us..
Anyway.. I couldn't find any ACPI specification about this matter. So this is a Microsoft thing.
> I have done some testing with starting the machine using the hotstart buttons and they report fine. Do you think you can
> update the code to output something whilst the machine is running normally? My laptop only has two buttons setup to start
> the machine out of a possible seven so I can't test everything. I would throw some code at you but I don't know C.
Not every laptop (such mine) reports runtime button presses through these devices, but I will do it in the next driver version.
> Any thoughts on what would need to be done to get this into the kernel?? It would definately fix many issues from what I
> have read. Not all my buttons produce scancodes or are even presented to linux. Critically the `rotate screen button`
> which I can use to signal the nvidia driver to rotate the screen.
We should get this driver stable and working with a big number of devices before asking to get this into the kernel tree.
Try the ACPI video module in the linux kernel. It should support the screen rotate button.
> I was looking through the acpi_toshiba and the omnibook drivers documentation. The acpi_toshiba driver seems to create
> an entry under /proc/acpi. Perhaps this would be a better place for the hotstart driver.
I was told on the ACPI mailing lists that /proc/acpi will disappear. Also if you read the CHANGELOG, you will see that version 0.01 was using profs :D
> Hope you don't mind these suggestions miknix, like I said I can't code in C otherwise I would have a go
Not a problem, this project is open to suggestions. :p
Yeah WMI is a Windows/MS thing. Unfortunately many of the laptops being released today have been tightly tied into the proprietary OS's way of doing things. In fact these buttons are part of MS's OnNow series. I think it will be difficult getting away from it. If this project were to continue to use the GHID method (or at least support it in addition to the ACPI spec) then I think a userspace config application could be helpful. Something that would list all the detected buttons and walk the user through assigning them to applications. Using the GHID value might be helpful for the user to correctly assign the keys rather than the e.g DBTN or QBTN which I am getting right now. Of course the label on the button helps :) acpid and hal and such like already have a method to respond to events. It would be a shame to have to do this over. Any way to use udev for this?
Actually for this driver to be more mainstream I think there *needs* to be a user tool to aid in configuration. A zenity or dialog script would do fine.
Re the screen rotation. If only things were that simple! On the tx1000 you have a choice. Acceleration or compatiblity (suspend/rotation etc). I am pretty shallow and acceleration/compizfusion will win everytime hehe.
Eagerly awaiting the next version.
Regs
R
> If this project were to continue to use the GHID method (or at least support it in addition to the ACPI spec) then I think
> a userspace config application could be helpful. Something that would list all the detected buttons and walk the user
> through assigning them to applications. Using the GHID value might be helpful for the user to correctly assign the keys
> rather than the e.g DBTN or QBTN which I am getting right now.
I think you are giving much hope to the returned buffer of GHID method.
Reading the microsoft paper gives:
>>The GHID method can return a BYTE, WORD, or DWORD. The value must be encoded in little-endian byte order (least significant byte first).<<
I don't see how a value like 0x02 would best describe a button, specially when it is vendor specific :D
lol I guess you are right
The driver is now reporting runtime button presses through kernel messages.
To enable this, load the module with enable_runtime_btns=1
$ modprobe quickstart enable_runtime_btns=1
Can you also send me your dsdt? To get it do:
cat /proc/acpi/dsdt > dsdt.bin
gzip dsdt.bin
Thanks!