Should a hardware display layer be reserved for the OS?

[slaeshjag]

On the Pandora, the third level is privileged, only root can draw to it anyway, so even if it were running in "user space" it would still need to be run as root anyway: it cannot, by intentional design, be run as the currently logged in user.


The idea was that this third layer would exist for the OS to give feedback and receive input from the user in a way that was (practically, for all intents and purposes) secure. The overlay experiment I did ran as a root user application but it really should have been deeper than that.

slaeshjag@pyra:~$ ls -lh /dev/fb*
crw-rw---- 1 root video 29, 0 Jan 1 1970 /dev/fb0
crw-rw---- 1 root video 29, 1 Jan 1 1970 /dev/fb1
crw-rw---- 1 root video 29, 2 Jan 1 1970 /dev/fb2

Developing such a deeply custom kernel module has several drawback. First of all, there's no chance in hell you'll be able to mainline it, so all maintenance will have to be done by the developer in their own tree.

Secondly, it makes it quite difficult for it to interact with userspace programs, so customizing and extending it will require mucking around with the kernel module.

Thirdly, a graphical input system that diverts input and overrides the display to show a uI isn't a driver in the first place, it's a system service. Might imply root, and it for sure implies userspace.

Kernelspace is where crashes can be fatal, so you don't want to add complexity in kernelspace if you don't need to.

Making it work in the first place will probably be a great PandoraGrade™ Hack™, since no matter if it runs in kernel space or userspace it'll need to hook all relevant input devices in a very non-standard way. Unless you do something silly that requires Xorg to be running.

Spoiler

I hope I didn't reach kingu-level of nonsense in this post...

 

[codifies]

Developing such a deeply custom kernel module has several drawback. First of all, there's no chance in hell you'll be able to mainline it, so all maintenance will have to be done by the developer in their own tree.

So?

Secondly, it makes it quite difficult for it to interact with userspace programs, so customizing and extending it will require mucking around with the kernel module.

Thats just not even an issue, to an Xorg it just looks like a keyboard...

that diverts input

Its not diverting anything it *is* the input, no reason why it can't *be* the touchscreen driver...

Kernelspace is where crashes can be fatal, so you don't want to add complexity in kernelspace if you don't need to.

it needn't be complex - its an input driver with a *very* simple graphical menu....

It need not hook anything and should not require Xorg nor qt etc...

 

[slaeshjag]

I suspect you want the top level overlay to do much less than most others want it to do...

 

[notaz]

I don't think this is worth even discussing, I had OMAP3's third layer reserved but nothing ever came out of it, only WizardStan's experiment, as he calls it.

And no doing it in kernel is a horrible idea, the kernel's design goes to great lengths to isolate/abstract device drivers away from each other, so you'd have to fight against the system to do it. If you want to be stuck to a single kernel version forever, then something could be done with some horrible hacks, but I don't think anyone wants that (to be stuck forever on single kernel release I mean).

BTW this is the reason pandora's controls are "done improperly" (as some people here like to claim) with many input devices instead of one. Userspace uinput deamon is the only bearable solution for that problem, but there was nobody to write one, only plenty of people to complain (as always).

 

[_wb_]

Userspace uinput daemon sounds like a good idea. If I understand correctly, it could for example be used to implement a "full-size keyboard compatibility mode", e.g. for use in DOSBox, so that if for example "+" is at Meta O, it would fake Shift = scancodes.

 

[Grench]

Userspace uinput daemon sounds like a good idea. If I understand correctly, it could for example be used to implement a "full-size keyboard compatibility mode", e.g. for use in DOSBox, so that if for example "+" is at Meta O, it would fake Shift = scancodes.

So... after all of the discussions and explanations you still don't understand the 'DosBox issue'?

Under DosBox:

Pressing shift and = will always result in + regardless of if + is marked on the = key. To get +, only the sanscodes of shift and = are read.

If the + is printed somewhere other than on the =+ key, it will either do nothing or something unpredictable. It quite literally has no idea what + is when mapped/printed by itself on a key.

Sorry for the keyboard discussion cross-over.

 

[codifies]

If its issuing scan codes, as far as dosbox is concerned its a classic IBM keyboard sending it the shift scancode then the = scancode the fact its some user configurable keyboard/touch screen combo is completely unknown to it, its just seeing scancode 0x2A then 0x0D *if* thats how you choose to configure it....

 

[_wb_]

Userspace uinput daemon sounds like a good idea. If I understand correctly, it could for example be used to implement a "full-size keyboard compatibility mode", e.g. for use in DOSBox, so that if for example "+" is at Meta O, it would fake Shift = scancodes.

So... after all of the discussions and explanations you still don't understand the 'DosBox issue'?

No no, I do understand the issue just fine. It's just that you don't understand the way in which it can be solved

 

[WizardStan]

So... after all of the discussions and explanations you still don't understand the 'DosBox issue'?

He's saying that, instead of "Meta"+"O" producing a scan code for "+", it actually produces scan codes for "shift" and "=". This technically solves the problem, and is effectively invisible to the user, but I'm pretty sure this would introduce more problems than it solves.

 

[_wb_]

So... after all of the discussions and explanations you still don't understand the 'DosBox issue'?

He's saying that, instead of "Meta"+"O" producing a scan code for "+", it actually produces scan codes for "shift" and "=". This technically solves the problem, and is effectively invisible to the user, but I'm pretty sure this would introduce more problems than it solves.

The only problem I can see is that it could interfere with actual Shift (including shoulder button Shift), but I don't think it's hard to solve that. AFAIU, ptitSeb did exactly this for qemu and I'm not aware of any problems. If we can do it at a global level (i.e. userspace uinput daemon), there is no need to manually modify DOSBox or any other application that is hardcoded for a standard US-QWERTY keyboard (or at least something with a physical ISO keyboard layout).

 

[bzar]

I see keyboard discussions seeping into this topic