Active Topics
-
Sailfish OS for the Motorola Moto G7 Power (XT1955-5) - (ocean) (3)
to SailfishOS by edp17 - 14 hrs, 31 mins ago -
The N900 is now 15 years old! (6)
to Nokia N900 by Macros - 1 day, 18 hrs ago -
F(x)tec Pro1x (QWERTY) for sale (0)
to Buy & Sell by aln00000 - 2 days, 7 hrs ago -
n770 youtube video (0)
to General by nmdv - 6 days, 6 hrs ago - more...
|
2014-01-31
, 19:28
|
|
Posts: 339 |
Thanked: 1,623 times |
Joined on Oct 2013
@ France
|
#462
|
Originally Posted by szopin
It looks like no one proposed the obvious solution : use the interrupt pin...
Software can act when it has sensor/input, not sure how software can magically sense keyboard open without it. Hopefully I am missing something
The only goal of this pin is for the other half to notify the phone that something is happening. In that case, when a key is pressed, the chip will trigger the interrupt pin, and the phone will know it has to check the chip for which key is pressed/released. No polling involved.
About the slide in/out of the keyboard, this could be done through a contact (for example both parts have a metal part on them, springy on one side, and when closed they enter in contact, or a "real" switch) which is connected as a standard key.
Keep up the good work dirkvl and kimmoli !
| The Following User Says Thank You to Zeta For This Useful Post: | ||
|
|
2014-01-31
, 19:32
|
|
Posts: 1,104 |
Thanked: 5,652 times |
Joined on Feb 2010
@ Holland
|
#463
|
Originally Posted by Zeta
This is already what we do, search for 'interrupt' in this thread
It looks like no one proposed the obvious solution : use the interrupt pin...
The only goal of this pin is for the other half to notify the phone that something is happening. In that case, when a key is pressed, the chip will trigger the interrupt pin, and the phone will know it has to check the chip for which key is pressed/released. No polling involved.
Originally Posted by Zeta
1 page back..
About the slide in/out of the keyboard, this could be done through a contact (for example both parts have a metal part on them, springy on one side, and when closed they enter in contact, or a "real" switch) which is connected as a standard key.
Originally Posted by dirkvl
Activating the keyboard will happen via software, so no open/close sensor.
 |
|
2014-01-31
, 19:47
|
|
Posts: 562 |
Thanked: 2,744 times |
Joined on Dec 2013
@ Espoo, Finland
|
#464
|
About the interrupt pin... atm it is exported to userspace... which works fine when phone is active.
Issue here is the deep-sleep where the phone goes. Seems that this interrupt-expoprted-to-userspace method is not able to wake-up the phone, so if it goes to sleep and you press a key on the keyboard .. nothing happens until something else triggers e.g. front proximity sensor is enough to wake up - then it processes the pending interrupt from the keyboard (and hopefully activates the screen - need a lot of dbus magic still (i don't want to restart mce service to get screen active))
Then i need little help with uinput (which is now used for sending the keys forward). The text/character appears to the screen only when i close the uinput 'device'. i can send there 10 keypresses, and they appear to screen at once when close(). Now creating a new uinput for every keypress doesn't sound efficient. (?)
Issue here is the deep-sleep where the phone goes. Seems that this interrupt-expoprted-to-userspace method is not able to wake-up the phone, so if it goes to sleep and you press a key on the keyboard .. nothing happens until something else triggers e.g. front proximity sensor is enough to wake up - then it processes the pending interrupt from the keyboard (and hopefully activates the screen - need a lot of dbus magic still (i don't want to restart mce service to get screen active))
Then i need little help with uinput (which is now used for sending the keys forward). The text/character appears to the screen only when i close the uinput 'device'. i can send there 10 keypresses, and they appear to screen at once when close(). Now creating a new uinput for every keypress doesn't sound efficient. (?)
| The Following User Says Thank You to kimmoli For This Useful Post: | ||
|
|
2014-01-31
, 21:02
|
|
Posts: 339 |
Thanked: 1,623 times |
Joined on Oct 2013
@ France
|
#465
|
Originally Posted by dirkvl
I expressed myself badly. I know you are using it for transfers, but wanted to say that it also is handy in the case where you would want to activate the keyboard when slided out, and there is no need for NFC or other more complex things proposed.
This is already what we do, search for 'interrupt' in this thread
Originally Posted by dirkvl
I read it. Just trying to give ideas for some future builds... Maybe a hall effect sensor with a magnet would be easier to build, but it probably would consume too much power...
1 page back..
Originally Posted by kimmoli
I though it would be handled by the kernel module which was talked about at the start (the I2C HID) ? If a kernel module was used, would it allow waking up the phone on interrupt ?
About the interrupt pin... atm it is exported to userspace... which works fine when phone is active.
Issue here is the deep-sleep where the phone goes. Seems that this interrupt-expoprted-to-userspace method is not able to wake-up the phone, so if it goes to sleep and you press a key on the keyboard .. nothing happens until something else triggers e.g. front proximity sensor is enough to wake up - then it processes the pending interrupt from the keyboard (and hopefully activates the screen - need a lot of dbus magic still (i don't want to restart mce service to get screen active))
|
|
2014-01-31
, 21:11
|
|
Posts: 562 |
Thanked: 2,744 times |
Joined on Dec 2013
@ Espoo, Finland
|
#466
|
Originally Posted by Zeta
NFC used to detect when keyboard is attached to the phone, like those regular TOHs from Jolla.
NFC or other more complex things proposed.
Originally Posted by Zeta
future maybe. Now plan is to activate it after a keypres. the onscreen keyboard can be activated too. this is still little TBD, as functionality is not yet so far implemented.
Maybe a hall effect sensor with a magnet would be easier to build
Originally Posted by Zeta
Kernel module is still TBD, it will be done if there is no way to get this work from userspace. I2C HID is not used, as it is not in the kernel. Maybe in some future updates by Jolla. (we are not providing custom kernel builds)
I though it would be handled by the kernel module which was talked about at the start (the I2C HID) ? If a kernel module was used, would it allow waking up the phone on interrupt ?
|
|
2014-02-01
, 14:20
|
|
Posts: 172 |
Thanked: 170 times |
Joined on Jan 2010
@ Sweden
|
#467
|
It might be possible to make a simple short-circuit signal between the keyboard top and bottom halves when opening/closing the keyboard.
That would require adding an extra element in the i2c stream, besides the data from the keyboard, and I don't know if you can do that. If that can't be done, how about a special gesture on the keyboard to turn it on/off? I.e. double alt, or something?
That would require adding an extra element in the i2c stream, besides the data from the keyboard, and I don't know if you can do that. If that can't be done, how about a special gesture on the keyboard to turn it on/off? I.e. double alt, or something?
|
|
2014-02-01
, 15:06
|
|
Posts: 1,104 |
Thanked: 5,652 times |
Joined on Feb 2010
@ Holland
|
#468
|
Originally Posted by stefanmohl
There seem to be a lot of questions about this subject, so some clarifications:
It might be possible to make a simple short-circuit signal between the keyboard top and bottom halves when opening/closing the keyboard.
That would require adding an extra element in the i2c stream, besides the data from the keyboard, and I don't know if you can do that. If that can't be done, how about a special gesture on the keyboard to turn it on/off? I.e. double alt, or something?
Hardware:
-there is no open/closed sensor
-the TCA8424 uses little power, especially in standby mode
Software:
-if we chose to cut of the power (3.3V) to the keyboard when it is not in use, we will probably turn the keyboard on when Mallit (on-screen keyboard is opened)
-if we chose not to cut of the power, we will put it in standby mode untill Mallit is opened
-When typing on the keyboard, I imagine it will be very practical to minimize the on-screen keyboard or replace it with special symbols/commands. But this is not something to discuss now!
Conclusion:
There are lots and lots and lots of way to streamline the use of the keyboard, which are all under consideration right now. Filling this thread with ideas/suggestions on how to do this will not help, although it is very friendly.
Send me a PM if you think you have a unique idea!
| The Following User Says Thank You to dirkvl For This Useful Post: | ||
|
|
2014-02-02
, 10:47
|
|
Posts: 1,104 |
Thanked: 5,652 times |
Joined on Feb 2010
@ Holland
|
#469
|
I sent all the people that pre-ordered via Paypal an email to confirm their address. Definitely not shipping yet, but cleaning up my room, my head and my administration 
 |
|
2014-02-02
, 10:56
|
|
Posts: 4,365 |
Thanked: 2,467 times |
Joined on Jan 2010
@ Australia Mate
|
#470
|
****, i just bought a n900 (used to have one).... that video, even though its poor quality/blurry, this keyboard OH looks simply amazing!
__________________
N9 / N900 Youtube Videos
N9 "Faster, Darker, Better" Theme Pack
---
www.F2thaK.com
N9 / N900 Youtube Videos
N9 "Faster, Darker, Better" Theme Pack
---
www.F2thaK.com
Probably. It will work fine, if I wasn't confident about that I would not put parts out for production. There is more than one way to skin a cat!
Last edited by dirkvl; 2014-01-31 at 13:52.