08-10-2020, 11:41 AM (This post was last modified: 08-10-2020, 09:32 PM by ideograph.
Edit Reason: refresh rate of eink keyboard is not very important, cheape panels could possibly be used
)
(07-30-2020, 12:59 AM)Gelectric Wrote: My plan is to use transparent keys on top of either an e-ink screen or a LCD, this would allow for customization of layouts and other cool things like kb adapting to applications.
I know that this goes beyond the scope of the published draft, but I have also worked on a concept based on this premise.
I think the most impressive aspect of this design will be to create the most subtle/clear way in which the "keys" are substantiated on the surface of the eink screen, so that when the keyboard is not in use, the screen can still be used to display other text etc. The clear, subtle bumps allow fingertip typing and then do not interfere with reading text or playing videos on the same screen. The more invisible the key "bumps" the better, the should be practically impossible to see (visual feedback provided by the screen below entirely) but the tactile feedback would come from the slight modification to screen surface.
Equally if not even more important than this versatility is the ability to use sliding "swipe" text on a screen-based haptic keyboard. Tactile keyboards are missed by many of us, but gliding is, in my opinion, one of the greatest ui innovation of all time. Blackberry Android keyboards have to some extent managed to combine sliding and hardware keys, but in my opinion they don't go far enough.
I'd love to be able to touch type and know which letter my finger is on without looking, but having to press their keys all the way down is a primarily an aesthetic, nostalgic thing, and not truly even in the top five benefits of a hardware keyboard. This non-clicky, tactile, touch screen keyboard would not break, feels comfortable and stable, and if you want to double the screen area, your keyboard is not useless but contributes to the display area. I would like to add also that a cheap eink screen, even with low refresh rate, would suffice for this type of keyboard, so long as it had a detailed enough touch sensor. There would be little/no animation during typing, so something like waveshare would be good enough. When reading books low refresh is also okay, though I am extremely optimistic about refresh on eink devices after seeing the hisense a5, which allow surprisingly comfortable video viewing.
Have you done any other work, or do you have other examples? It may not be the simplest design to start with, but I think it's one of the most minimalist in the long run and not too expensive to make, considering how functional it is. It could be worthwhile to develop independently and I would be happy to be contacted.
It could be great to have a keyboard for the Pinephone, hopefully compatible with the future iteration of the device (who knows, maybe a Pinephone 2 or 3?). The TOHKBD was an amazing project, I regret to not have bought one for my beloved Jolla (which I still have, sleeping in a draw). Such a shame that Jolla stopped doing hardware and all the existing devices aren't compatible with this amazing piece of hardware.
I will not miss the opportunity this time!
this keyboard no have capslock, but why have ins?
Meybe add more than one function key? this keyboard are small, meybe add fn0..2 ?and normal Function N F1, F2...
@x0r
WEll, tbh it actually has Caps, bottom-left area. Ins and the rest have been added for improved Terminal experience, but those buttons are clearly secondary to the D-pad.
this keyboard no have capslock, but why have ins?
Meybe add more than one function key? this keyboard are small, meybe add fn0..2 ?and normal Function N F1, F2...
@x0r
WEll, tbh it actually has Caps, bottom-left area. Ins and the rest have been added for improved Terminal experience, but those buttons are clearly secondary to the D-pad.
To all: thanks for all the support!
No, capslock are not a key. This is modyficator and key.
I have no problem with modyficator but useless ins are not good idea.
I would like normal PgUp key not modyficator.
capslock are a 'switch key' you put it sometime, pgup is more usefull and more necessary.
It's open source licensed, it had several production iterations already, and it's similar to BlackBerry keyboards (which are generally better than the Nokia keyboard mentioned in requirements).
The F1-F4 buttons could be put to sides to make 6 rows into 5. Note also, that the "narrowness" of the keyboard should be preserved even if more space is available on PinePhone. Otherwise it'd harm ergonomy a lot (don't underestimate this!).
Btw. do you plan to have the keyboard touch sensitive for scrolling etc. like BlackBerry/Unihertz? It's an extremely useful feature highly increasing keyboard productivity right on touch devices (it avoids leaving the keyboard and feels really seamless).
There are also other interesting designs which has proven slightly better than the Nokia design - e.g. Unihertz Titan. But there are no designs available under open source licenses (though the design itself is not patented and itself is to my knowledge made in a way which is not infringing any BlackBerry patents).
The main focus was simplicity in design (and manufacturing) while not sacrificing capability wherever possible. Here are the highlights:
Ability to use headphone and USB Type-C jack while in use. Requires 90 degree adapter or cord
Power and data delivered through the pogo pins
Landscape layout for better weight distribution
I forgot to add it to the drawing, but there will also be a cut out for the speaker and microphone.
For the electronics, I plan to construct it with 3 PCBs:
Main board - Contains STM32G070KBT6 (0.86 USD in quantities > 1000) and pogo pin connector
Left gamepad board - All buttons and trigger connections for the left half. Connects to main board with an FFC.
Right gamepad board - All buttons and trigger connections for the righthalf. Connects to main board with an FFC.
Software-wise, my initial plan is for the STM32G070KBT6 to be running firmware compatible with HID over I2C. There is already a kernel driver for this protocol. This firmware needs to be written, but from how I understand it, it doesn't appear to be too complex.
For the housing, I went back and forth on adding a slide out or quick-detach mechanism. In the end, I decided to keep it simple for now and stick with strictly a back cover replacement. If viable sliding/quick-detach mechanisms come out of the keyboard contest, I'd be interested in working with those project leaders to be compatible, allowing you to swap out a keyboard for gamepad and vice versa.
I'm working on CAD for the housing now. Once I have a layout I'm happy with I'm planning on moving to PCB design. I'm hoping to keep a log of my work on the wiki: https://wiki.pine64.org/index.php?title=...ne_gamepad
Question is, why this keyboard is only for sms, not for terminal.
This phone is for hackers from hackers. After 5 hours you will start to swear that the keyboard is not usable in mc/ssh etc.
Question is, why this keyboard is only for sms, not for terminal.
This phone is for hackers from hackers. After 5 hours you will start to swear that the keyboard is not usable in mc/ssh etc.
The keyboard for pinephone ISN'T going to only be for sms, at least I haven't seen anything that said that.
(08-08-2020, 03:31 AM)Boern Wrote: I think I saw somewhere the option to use the touchscreen as a touchpad. So you wouldn't actually need a dedicated touchpad if that is implemented in your OS.
It would probably work but your finger would have to block parts of the screen while using it as a touchpad.
(08-08-2020, 05:35 AM)SwordfishII Wrote:
(08-08-2020, 12:08 AM)Djhg2000 Wrote: There is one thing I'd like to add though; since it might be desirable to use legacy X11 applications on a PinePhone (unlike on a Jolla Phone)
A solution I used on a Linux tablet that only had a keyboard was keynav and a custom keybinding that initialized on startup.
Basically it sets up a 4 square grid. If you cut right it turns the right two grids into 4 grids (one move eliminated half the screen) again using a direction, up, down, left or right you reduce that half by another half. You can keep going if you want but the goal is to have the center + where you want the mouse to go. Then you use a designated mouse click button and the mouse moves to that spot and either right, left or center clicks.
It sounds confusing but it is really simple and useful if you don't have/want a mouse.
The video shows the default bindings but it's easy to change them. He also cuts more than he has to but it shows how accurate it is.
It works surprisingly well and quickly, although gaming is definitely out.
That is really cool. Kind of cumbersome compared to an actual pointing device but still cool.