booboo wrote:I'm not sure if there are enough applications that need a keyboard and are worth porting to the A320. At least not enough applications as to make the effort you're doing.
Applications I can think of: file managers, IM, web, etc (I'm kinda ambitious here, and I also have future / other devices in mind).
It's also supposed to be a full-fledged UI for dingoo linux in the future, and implementing the KB (and your volume / brightness stuff) could serve as a basis for that.
booboo wrote:That said, I'm all for ANY application/tool/library that has the potential to draw developers and new apps to the A320, so here are my two cents:
- The input capabilities of the A320 are so minimal (as compared to a mouse or a full keyboard) that you must concentrate in making the keyboard FAST and easy to use. I don't think a mouse is the way to go here. I suggest a traslucent key matrix which you can navigate with up/down/left/right/start/select. Start could be ENTER and SELECT could be ESC. Speed could be improved by splitting the key matrix in two halves and make each selectable with the shoulder buttons.
This sounds like a really good idea, and I think we should go for it. We could reduce the matrix size even more by making the shoulder buttons "modifiers", and thus having a default mode (no shoulder button pressed) and 2 other modes for each shoulder button pressed, respectivly. This might be impracticable, though (even with only two modes).
booboo wrote:- Having an emulated mouse would be great too for applications that need it but don't already emulate it with up/down/left/right.
Yeah I have this working, only needs time-based input acceleration (curser moves faster the longer it moves). It uses gpm, and this might be little ankward, but it saves me from writing a mouse driver (and it will work on future devices, as long there is a joystick device). It also has the benefit of fixing a bug in gpm.
booboo wrote:- Either the on-screen keyboard is a library and programs are compiled against it, or you just CANNOT SHARE the framebuffer device. There are things like fbui, but programs must be modified to use it.
Oh, I didn't know that the framebuffer could not be shared (though this was one of the things I had quietly feared
). I planned to do the input and all other stuff transparently to the applications, so that there are no modifications neccessary and developers can quickly port stuff. In the future we could provide a optional library which interfaces with the daemon, if we ever have any functionality in there worth exposing to applications (ATM I can't think of any, but I'm sure someone will come up with something
).
booboo wrote:There are a couple of features I'm still to implement in the linux kernel for A320: volume and brightness control. Here I have two choices:
1- Do it all in the kernel.
2- Do it in user space (using uinput and the sound system and brightness control device).
Doing it all in the kernel is tempting: it is dead simple. You lose flexibility but the A320 is a very specialized system anyway. One thing that I would like to do is to show some overlay information on screen when you trun the volume or brightness up/down, and I faced the same sharing problem: I cannot show that info onscreen while another program is using the framebuffer. So I though I could do it all in kernel: keeping a double buffer in the framebuffer driver and do the overlay in software. It is an expensive operation in terms of cpu usage, but the overlay will be shown only a few seconds and whatever the user was doing he would have paused it to raise/lower the volume/brightness anyway.
Now I think your on-screen keyboard is also a great candidate to be implemented in a similar way. However, it implements a quite complex functionality and I don't think it should go in the kernel. So, what do we do?.
Here's a solution: I can modify the framebuffer driver so it creates TWO framebuffer devices. The first one would be the "standard" one, and the second would be the "traslucent overlay" one. The driver would "blend" both only when the second is in use.
Then, you can program a daemon that uses the traslucent overlay framebuffer and implements:
- On-screen keyboard.
- LCD brightness control.
- Audio volume control.
I think it should go into user-space. The second framebuffer sounds like a great idea. We can run SDL on top of it and use guichan without any modifications by just pointing it to the second FB, though I could imagine writing a special backend if neccessary.
Using guichan is overkill for these simple things, but some kind of UI library will be neccessary in the future. Also, if anybody knows a better, lightweight UI lib which runs on top of SDL / FB, please let me know. It seems decent enough though, and there already is a way to define UIs in xml , which will make skinning easy.
booboo wrote:What do you think?
I think this was some good input.
