Hi Matteo,
you patch will basically work as expected,
however I think this is not enough to make the whole thing usable the major problem is that
you can't say if the user pressed the say Fn+F6 key one time or say five times so you don't
know if you have to dim the backlight level by 1 or by 5.
What we miss here is either an interrupt mechanism which is triggered each Fn keypress (it's the scancode 0x6d stuff)
OR something to poll where we can read "an fnkey as been pressed" and for which we can write "ok acknowledge" and for which we then loop reading "no fnkey pressed since last ack." until it changes to "an fnkey as been pressed" then we call detect the last pressed scancode for each actual keypress.
Such address to poll MAY exist: according to the Tecra S1 documentation you can try to call nbsmi_ec_read_command(0x8f,*data)
it should return (in data): 0 if no fnkey was pressed 1 if a key was pressed once and 3 if pressed twice. The doc does not gives any more details. _But_ if nbsmi_ec_write_command(8f, 0) works reseting the result of nbsmi_ec_read_command(0x8f,*data) back to 0 _Then_ we have our polling mechanism. You can try to hack around that, I cannot without the actual hardware.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You are right, the hack works if you watch /proc/omnibook/lastfn very frequently (ie 0.1 sec), this makes it quite usable, but I'll try to develop the queue mechanism.
I have a Satellite M40 and I don't get the scancode you mentioned (0x6d), this makes the thing harder but, as you say, there might be a pooling mechanism, so let's try.
in position 0x91 I find the last fn pressed (Fn+Esc), why that? It is supposed to be in 0xab.. moreover I don't find the fnpressed in 0x8f, it is always blank. What am I doing wrong? Omnibook finds the actual fn pressed, there is something that I don't understand.
Thanks,
Matteo
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi.
Concerning reading lastfn at even high frequency,
can you tell how many time the same Fn+foo key was pressed consecutively ?
Concerning your observations of index mismatch :this is prefectly normal, have a deeper look at the nbsmi.c code, you will see that
nbsmi_ec_read/write_command look for a index/data register a ioport 0x300, this is very different from the EC address space.
The fact that you also have the last pressed scancode at index 0x91 of the EC address space is indeed a discovery.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> Concerning reading lastfn at even high frequency,
> can you tell how many time the same Fn+foo key was pressed consecutively
> ?
No, but as long as the user doesn't press fn+foo twice in less than 0.1 seconds who cares? If the user is "that slow" we will catch every single pression and execute the right command.
> Concerning your observations of index mismatch :this is prefectly normal,
> have a deeper look at the nbsmi.c code, you will see that
> nbsmi_ec_read/write_command look for a index/data register a ioport 0x300,
> this is very different from the EC address space.
ok, now that I'm doing some trial and error on "Read and write utility" (http://home.kimo.com.tw/ckimchan.tw/) and the picture is more clear.
Now I understand that the meaning of "ec" in sbsmi_ec_read/write_command is extended cmos and not embedded controller.. so if I look at the right place (ioport 0x300 extended cmos in R&W utility) I find the following:
- 0xa5: last fn pressed
- 0xaa: FnPressed (0/1 depending if fn key pressed in queue or not)
- 0x8f: fix to value 40 except when you press fn key when value becames 41 (this is indipendent to fn+foo, it activates also if _ONLY_ fn is pressed and stays to 41 until you release fn)
- 0x95: contains the current brightness level
So I guess Satellite M40 is different than Tecra S1. Now I go back hacking lastfn.c.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
if I look at the extended cmos ioport 0x300 index 0xaa and set refresh frequency to 0.1 it is impossible to see the famous value "3" wich reports that fn+foo has been pressed twice. I was able to see it only once, at the same time setting refresh frequency so high causes the comp to turn the fan on.. so we should avoid doing it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
lastfn.c
Logged In: YES
user_id=1435472
Originator: NO
Hi Matteo,
you patch will basically work as expected,
however I think this is not enough to make the whole thing usable the major problem is that
you can't say if the user pressed the say Fn+F6 key one time or say five times so you don't
know if you have to dim the backlight level by 1 or by 5.
What we miss here is either an interrupt mechanism which is triggered each Fn keypress (it's the scancode 0x6d stuff)
OR something to poll where we can read "an fnkey as been pressed" and for which we can write "ok acknowledge" and for which we then loop reading "no fnkey pressed since last ack." until it changes to "an fnkey as been pressed" then we call detect the last pressed scancode for each actual keypress.
Such address to poll MAY exist: according to the Tecra S1 documentation you can try to call nbsmi_ec_read_command(0x8f,*data)
it should return (in data): 0 if no fnkey was pressed 1 if a key was pressed once and 3 if pressed twice. The doc does not gives any more details. _But_ if nbsmi_ec_write_command(8f, 0) works reseting the result of nbsmi_ec_read_command(0x8f,*data) back to 0 _Then_ we have our polling mechanism. You can try to hack around that, I cannot without the actual hardware.
Logged In: YES
user_id=1701745
Originator: YES
You are right, the hack works if you watch /proc/omnibook/lastfn very frequently (ie 0.1 sec), this makes it quite usable, but I'll try to develop the queue mechanism.
I have a Satellite M40 and I don't get the scancode you mentioned (0x6d), this makes the thing harder but, as you say, there might be a pooling mechanism, so let's try.
if I do
$ cat /proc/omnibook/dump
EC +00 +01 +02 +03 +04 +05 +06 +07 +08 +09 +0a +0b +0c +0d +0e +0f
EC 0x00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
EC 0x10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
EC 0x20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
EC 0x30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 69
EC 0x40: 22 00 00 3f 01 89 89 00 00 00 00 00 00 00 00 00
EC 0x50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
EC 0x60: 00 00 7d 25 f6 64 40 e0 40 f7 fe ff 57 80 02 0a
EC 0x70: 03 de ee ca df 60 01 14 0e 7b fd e9 d5 06 42 10
EC 0x80: 9a ef 7f 0a 6f 0a 9e 02 00 00 00 00 00 00 00 00
EC 0x90: 11 *01 08 fb 01 10 00 00 00 0a 02 00 *2f 2d 40 68
EC 0xa0: 01 00 01 07 64 00 00 00 8f 0b 8f 0b cc 10 00 00
EC 0xb0: 00 00 00 00 02 00 00 03 00 4b 05 00 00 00 00 00
EC 0xc0: 00 64 66 55 5a 00 00 40 ff 03 01 3b *00 00 2c 36
EC 0xd0: 00 00 00 01 00 00 00 00 00 00 00 00 01 00 00 00
EC 0xe0: c8 02 79 50 05 e0 1d 00 db 00 28 80 fc 00 00 61
EC 0xf0: ef 00 00 fe 02 37 ff 06 00 30 30 02 *2d ff 00 00
in position 0x91 I find the last fn pressed (Fn+Esc), why that? It is supposed to be in 0xab.. moreover I don't find the fnpressed in 0x8f, it is always blank. What am I doing wrong? Omnibook finds the actual fn pressed, there is something that I don't understand.
Thanks,
Matteo
Logged In: YES
user_id=1435472
Originator: NO
Hi.
Concerning reading lastfn at even high frequency,
can you tell how many time the same Fn+foo key was pressed consecutively ?
Concerning your observations of index mismatch :this is prefectly normal, have a deeper look at the nbsmi.c code, you will see that
nbsmi_ec_read/write_command look for a index/data register a ioport 0x300, this is very different from the EC address space.
The fact that you also have the last pressed scancode at index 0x91 of the EC address space is indeed a discovery.
Logged In: YES
user_id=1701745
Originator: YES
> Concerning reading lastfn at even high frequency,
> can you tell how many time the same Fn+foo key was pressed consecutively
> ?
No, but as long as the user doesn't press fn+foo twice in less than 0.1 seconds who cares? If the user is "that slow" we will catch every single pression and execute the right command.
> Concerning your observations of index mismatch :this is prefectly normal,
> have a deeper look at the nbsmi.c code, you will see that
> nbsmi_ec_read/write_command look for a index/data register a ioport 0x300,
> this is very different from the EC address space.
ok, now that I'm doing some trial and error on "Read and write utility" (http://home.kimo.com.tw/ckimchan.tw/) and the picture is more clear.
Now I understand that the meaning of "ec" in sbsmi_ec_read/write_command is extended cmos and not embedded controller.. so if I look at the right place (ioport 0x300 extended cmos in R&W utility) I find the following:
- 0xa5: last fn pressed
- 0xaa: FnPressed (0/1 depending if fn key pressed in queue or not)
- 0x8f: fix to value 40 except when you press fn key when value becames 41 (this is indipendent to fn+foo, it activates also if _ONLY_ fn is pressed and stays to 41 until you release fn)
- 0x95: contains the current brightness level
So I guess Satellite M40 is different than Tecra S1. Now I go back hacking lastfn.c.
Logged In: YES
user_id=1701745
Originator: YES
if I look at the extended cmos ioport 0x300 index 0xaa and set refresh frequency to 0.1 it is impossible to see the famous value "3" wich reports that fn+foo has been pressed twice. I was able to see it only once, at the same time setting refresh frequency so high causes the comp to turn the fan on.. so we should avoid doing it.