Fbcon: Keysyms wrong & cannot switch VT after hang

As the subject states, two problems.
Hopefully someone has some suggestions.

Both on the fbcon-target.

  1. The keys are mapped completely wrong. I know, I’ve got
    a powermac, that’s why. I resolved it by editting em all,
    but e.g. libgii does this much nicer, by questioning the
    kernel for the mappings. I don’t see this as a big problem
    (I just patch the thing) but maybe someone likes to code
    this kernel questioning to settle this for good.

(Maybe I should ask this somewhere else)
2) This is more annoying. Sometimes, when coding, you
make a mistake. You know, sometimes. The problem is that
when your program hangs, it’s hard to quit. And, in the
end you resort to kill -9 BUT this is not possible with
fbcon, as you cannot switch consoles. My current
solution, debug in X11 and play in fbcon is not very
pleasing. Any suggestions? Keys in a seperate thread?
Autokill after a certain idle period?

Thanks for responses,
Niels

  1. The keys are mapped completely wrong. I know, I’ve got
    a powermac, that’s why. I resolved it by editting em all,
    but e.g. libgii does this much nicer, by questioning the
    kernel for the mappings. I don’t see this as a big problem
    (I just patch the thing) but maybe someone likes to code
    this kernel questioning to settle this for good.

SDL does query the kernel for key mappings, see FB_vgainitkeymaps()
Is there a better way to do this?

(Maybe I should ask this somewhere else)
2) This is more annoying. Sometimes, when coding, you
make a mistake. You know, sometimes. The problem is that
when your program hangs, it’s hard to quit. And, in the
end you resort to kill -9 BUT this is not possible with
fbcon, as you cannot switch consoles. My current
solution, debug in X11 and play in fbcon is not very
pleasing. Any suggestions? Keys in a seperate thread?
Autokill after a certain idle period?

Try kill -3 instead of kill -9. SDL tries to gracefully quit when
it receives this signal, unless you’ve overridden it for some reason.

See ya,
-Sam Lantinga, Lead Programmer, Loki Entertainment Software

sdl at lokigames.com (Sam Lantinga) wrote in <E12y0eB-0000CP-
00 at roboto.devolution.com>:

Thanks for the response Sam, however I’m afraid you
misunderstood me in both cases. Let me try to be more clear.

  1. The keys are mapped completely wrong. I know, I’ve got
    a powermac, that’s why. I resolved it by editting em all,
    but e.g. libgii does this much nicer, by questioning the
    kernel for the mappings. I don’t see this as a big problem
    (I just patch the thing) but maybe someone likes to code
    this kernel questioning to settle this for good.

SDL does query the kernel for key mappings, see FB_vgainitkeymaps()
Is there a better way to do this?

This is indeed the case. HOWEVER this is only used with
Unicode, which I do not use. (Maybe the devel release has bettered
this?) My idea was to extend this to the kesym.sym value.
By the way, why in the first place, use it for Unicode alone??

(Maybe I should ask this somewhere else)
2) This is more annoying. Sometimes, when coding, you
make a mistake. You know, sometimes. The problem is that
when your program hangs, it’s hard to quit. And, in the
end you resort to kill -9 BUT this is not possible with
fbcon, as you cannot switch consoles. My current
solution, debug in X11 and play in fbcon is not very
pleasing. Any suggestions? Keys in a seperate thread?
Autokill after a certain idle period?

Try kill -3 instead of kill -9. SDL tries to gracefully quit when
it receives this signal, unless you’ve overridden it for some reason.

Let me say it in another way: when running a flawed program
on the framebuffer, and when it does NOT crash but instead
loops forever, then by system is essentially blocked.
I cannot type anything. I cannot switch VT’s. I may as well throw
my keyboard out of the window. I have to resort to either
log in remotely (which is not a nice option for me) or reset
the computer (which is a Bad Thing). So, my question was:
is there an elegant way to alleviate this? Apart from forgetting
fb and debugging in X11?

Niels>See ya,

-Sam Lantinga, Lead Programmer, Loki Entertainment Software

Let me say it in another way: when running a flawed program
on the framebuffer, and when it does NOT crash but instead
loops forever, then by system is essentially blocked.
I cannot type anything. I cannot switch VT’s. I may as well throw
my keyboard out of the window.

Pardon my ignorance, but why doesn’t the virtual terminal switch work?
Isn’t the Right Solution to make it work instead?

(Many kernel and/or graphics hackers I know keep an old vt100 around
for this kind of stuff. The cost is almost negative - people will pay you for
taking them away - and it’s great for the occasional serial console, gdb, or
nethack.)

SDL does query the kernel for key mappings, see FB_vgainitkeymaps()
Is there a better way to do this?

This is indeed the case. HOWEVER this is only used with
Unicode, which I do not use. (Maybe the devel release has bettered
this?) My idea was to extend this to the kesym.sym value.
By the way, why in the first place, use it for Unicode alone??

Ahh, I see. I’ll take a look at the GII code sometime and try to
improve the mapping. It will probably be some time before I get a
chance to do this, so if you want to submit a patch, you are more
than welcome. :slight_smile:

Let me say it in another way: when running a flawed program
on the framebuffer, and when it does NOT crash but instead
loops forever, then by system is essentially blocked.
I cannot type anything. I cannot switch VT’s. I may as well throw
my keyboard out of the window. I have to resort to either
log in remotely (which is not a nice option for me) or reset
the computer (which is a Bad Thing). So, my question was:
is there an elegant way to alleviate this? Apart from forgetting
fb and debugging in X11?

I see your problem, and the answer is no, you’re probably better
off debugging in X11 until your program is fully debugged. SDL
doesn’t create a watchdog thread to make sure your program is still
responding. Heheh. I’ve seen people use gpm to monitor the mouse
port and respond to certain button combinations with predefined actions.
I’ve never done this myself, so your mileage may vary, but SDL should
detect that gpm is running and if gpm was passed the -R (repeater) option,
SDL will be able to use it for mouse input.

Good luck!
-Sam Lantinga, Lead Programmer, Loki Entertainment Software

Hello Sam, to continue on my newsgroup questions,
I pondered your answers and solved my problems.
I also have a diff you may want to use.

On 03 jun 2000, you wrote in loki.open-source.sdl:

SDL does query the kernel for key mappings, see FB_vgainitkeymaps()
Is there a better way to do this?

This is indeed the case. HOWEVER this is only used with
Unicode, which I do not use. (Maybe the devel release has bettered
this?) My idea was to extend this to the kesym.sym value.
By the way, why in the first place, use it for Unicode alone??

Ahh, I see. I’ll take a look at the GII code sometime and try to
improve the mapping. It will probably be some time before I get a
chance to do this, so if you want to submit a patch, you are more
than welcome. :slight_smile:

Well, I followed up to your advice. I attached a patch,
hope it’s a format you can use. With the patch, you can ditch
SDL_fbkeys.h, and the frame buffer key code should behave
more platform independant now. On my Apple powermac (type 7600,
clone keyboard) it all works swell now, but I’m afraid you need
to hack the windows keys c.s. in again, as I obviously do not have
those.

Let me say it in another way: when running a flawed program
on the framebuffer, and when it does NOT crash but instead
loops forever, then by system is essentially blocked.
I cannot type anything. I cannot switch VT’s. I may as well throw
my keyboard out of the window. I have to resort to either
log in remotely (which is not a nice option for me) or reset
the computer (which is a Bad Thing). So, my question was:
is there an elegant way to alleviate this? Apart from forgetting
fb and debugging in X11?

I see your problem, and the answer is no, you’re probably better
off debugging in X11 until your program is fully debugged. SDL
doesn’t create a watchdog thread to make sure your program is still
responding. Heheh. I’ve seen people use gpm to monitor the mouse
port and respond to certain button combinations with predefined actions.
I’ve never done this myself, so your mileage may vary, but SDL should
detect that gpm is running and if gpm was passed the -R (repeater) option,
SDL will be able to use it for mouse input.

Sheesh… This took me two days to find out I cannot get it to
work. Luckily, a following brainwave gave me a better idea. As I
switched to an USB mouse recently, I now happily use the single button
of my spare ADB mouse to signal a 'killall ’ (this is a
separate program.) Hurrah.

Good luck!
-Sam Lantinga, Lead Programmer, Loki Entertainment Software

Same to you, I hope you let me know if the patch works.

Niels Roest

-------------- next part --------------
A non-text attachment was scrubbed…
Name: diff-keycodes
Type: application/octet-stream
Size: 9916 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20000613/ac793134/attachment.obj

Well, I followed up to your advice. I attached a patch,
hope it’s a format you can use. With the patch, you can ditch
SDL_fbkeys.h, and the frame buffer key code should behave
more platform independant now. On my Apple powermac (type 7600,
clone keyboard) it all works swell now, but I’m afraid you need
to hack the windows keys c.s. in again, as I obviously do not have
those.

Thanks, I’ll test those with a PC keyboard and apply your patch.

Same to you, I hope you let me know if the patch works.

Will do.

Thanks!
-Sam Lantinga, Lead Programmer, Loki Entertainment Software