Non-technical story:
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!
Software can act when it has sensor/input, not sure how software can magically sense keyboard open without it. Hopefully I am missing something
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.
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.
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.
This is already what we do, search for 'interrupt' in this thread
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.
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. (?)
This is already what we do, search for 'interrupt' in this thread
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.
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...
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))
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 ?
Maybe a hall effect sensor with a magnet would be easier to build
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.
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 ?
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)
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?
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?
There seem to be a lot of questions about this subject, so some clarifications:
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!
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
