Are there any known issues with keyboard events and the linux framebuffer? I
have no problems capturing keyboard events in X but the events do not seem to
fire in the framebuffer.
Thanks for any help,
-Ryan Provencher
I used to think the same. Remember, to use the
keyboard events SDL_InitVideoMode should preceed
PollEvents. Also using pointers and checking keyboard
states works very well. IF you think theres a problem
write a minimalist prog that demonstrates it and
preferably other info with it too like the output
after a gcc -Wall compile.
— Ryan Provencher <ryan.provencher at verizon.net>
wrote:> Are there any known issues with keyboard events and
the linux framebuffer? I
have no problems capturing keyboard events in X but
the events do not seem to
fire in the framebuffer.
Thanks for any help,-Ryan Provencher
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/
on 8/16/01 6:30 AM, Ghazan Haider at ghazanhaider at yahoo.com wrote:
I used to think the same. Remember, to use the
keyboard events SDL_InitVideoMode should preceed
PollEvents. Also using pointers and checking keyboard
states works very well. IF you think theres a problem
write a minimalist prog that demonstrates it and
preferably other info with it too like the output
after a gcc -Wall compile.
I’ve had problems with reading the keyboard under the framebuffer console,
but I don’t recall the exact situation. There may well be a bug in SDL’s
keyboard code. To slightly twist a Linus Torvalds quote, Linux console
programming can be used to frighten small children…
-John
Hello everybody,
I face similar problems. When I use the fbcon target video and audio are
processed correctly. But input (keyboard/mouse) doesn’t work at all,
even console switching or kernel SysReq keys. Others applications that
use framebuffer seems to work though (I’ve been successfull with mplayer
at least), so this may be a bug in SDL input code? I’m using SDL 1.2.2
on a Linux 2.4.2 kernel with a Voodoo 3 card.
Alex.On 23 Aug 2001 13:33:13 -0400, John R. Hall wrote:
I’ve had problems with reading the keyboard under the framebuffer console,
but I don’t recall the exact situation. There may well be a bug in SDL’s
keyboard code. To slightly twist a Linus Torvalds quote, Linux console
programming can be used to frighten small children…
I face similar problems. When I use the fbcon target video and audio are
processed correctly. But input (keyboard/mouse) doesn’t work at all,
even console switching or kernel SysReq keys. Others applications that
use framebuffer seems to work though (I’ve been successfull with mplayer
at least), so this may be a bug in SDL input code? I’m using SDL 1.2.2
on a Linux 2.4.2 kernel with a Voodoo 3 card.
I just started paying attention to this thread, so sorry if this is a
repeat request. Can someone send me a minimal example program so I can
look into this?
–ryan.
As it is really simple, I’ve attached it to this mail. The program
simply fills the screen with a cycling color, to make sure the program
hasn’t crashed, and exits once you press any key. It runs successfully
with x11 and svgalib targets, but with fbcon target the input doesn’t
work. Even the NumLock key. I simply have to hard-reboot my machine to
get out of it 
Hope this will help!
Alex.
-------------- next part --------------
A non-text attachment was scrubbed…
Name: sdltest.c
Type: text/x-c
Size: 609 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20010824/2b48634c/attachment.binOn 24 Aug 2001 04:36:24 -0400, Ryan C. Gordon wrote:
I face similar problems. When I use the fbcon target video and audio are
processed correctly. But input (keyboard/mouse) doesn’t work at all,
even console switching or kernel SysReq keys. Others applications that
use framebuffer seems to work though (I’ve been successfull with mplayer
at least), so this may be a bug in SDL input code? I’m using SDL 1.2.2
on a Linux 2.4.2 kernel with a Voodoo 3 card.I just started paying attention to this thread, so sorry if this is a
repeat request. Can someone send me a minimal example program so I can
look into this?
It is not the solution to the Framebufferproblem, but you have to use
SDL_Init (SDL_INIT_VIDEO); and SDL_Quit ();
CU
“Alexandre Courbot” schrieb im Newsbeitrag news:mailman.998645706.14366.sdl at libsdl.org…> On 24 Aug 2001 04:36:24 -0400, Ryan C. Gordon wrote:
I face similar problems. When I use the fbcon target video and audio are
processed correctly. But input (keyboard/mouse) doesn’t work at all,
even console switching or kernel SysReq keys. Others applications that
use framebuffer seems to work though (I’ve been successfull with mplayer
at least), so this may be a bug in SDL input code? I’m using SDL 1.2.2
on a Linux 2.4.2 kernel with a Voodoo 3 card.I just started paying attention to this thread, so sorry if this is a
repeat request. Can someone send me a minimal example program so I can
look into this?As it is really simple, I’ve attached it to this mail. The program
simply fills the screen with a cycling color, to make sure the program
hasn’t crashed, and exits once you press any key. It runs successfully
with x11 and svgalib targets, but with fbcon target the input doesn’t
work. Even the NumLock key. I simply have to hard-reboot my machine to
get out of itHope this will help!
Alex.
Another thing, when i compile sdltest.c ( with SDL_FULLSCREEN option )
the SDL_FillRects overpaint the Mousecursor. Is this normal behaviour ???
Normaly if i don?t use SDL_ShowCursor (0); the cursor should be visible alltime.
Or was it a problem implementing that with DirectX ???
CU
As it is really simple, I’ve attached it to this mail. The program
simply fills the screen with a cycling color, to make sure the program
hasn’t crashed, and exits once you press any key. It runs successfully
with x11 and svgalib targets, but with fbcon target the input doesn’t
work. Even the NumLock key. I simply have to hard-reboot my machine to
get out of it
It works here, or rather crashes predictably:
I get a key event, the loop ends, and since we didn’t call SDL_Quit(), the
framebuffer is left in an unpredictable state (video apparently frozen,
input definitely frozen). When I call SDL_Quit() before returning from
main(), SDL cleans up correctly and the system continues to work. This, as
far as I’m concerned, makes it either a bug in fbcon (if users can hijack
the console), or just an unfortunate design choice on fbcon’s part. Either
way, it’s not SDL’s fault.
Was this the problem, or are you not even getting key events in the first
place? I’m not using the latest CVS of SDL, so it might be a newer bug
than my codebase has. Let me know.
–ryan.
I get a key event, the loop ends, and since we didn’t call SDL_Quit(), the
framebuffer is left in an unpredictable state (video apparently frozen,
input definitely frozen). When I call SDL_Quit() before returning from
main(), SDL cleans up correctly and the system continues to work. This, as
far as I’m concerned, makes it either a bug in fbcon (if users can hijack
the console), or just an unfortunate design choice on fbcon’s part. Either
way, it’s not SDL’s fault.
Ooops. I forget SDL_Quit, yeah. I probably made you hard-rebooting, my
apologies for that.
Was this the problem, or are you not even getting key events in the first
place? I’m not using the latest CVS of SDL, so it might be a newer bug
than my codebase has. Let me know.
Actually, I don’t even get the key events in the program loop. That is,
even with SDL_Quit, I CAN’T quit the program because the keyboard is
totally stuck. The screen is properly updated on the other hand, this
proves the program doesn’t crash. As others fb applications does work
properly, I think the bug isn’t related to the framebuffer code (unless
there are different ways to get the input from the fb console).
Alex.On 24 Aug 2001 06:23:25 -0400, Ryan C. Gordon wrote:
Actually, I don’t even get the key events in the program loop. That is,
even with SDL_Quit, I CAN’T quit the program because the keyboard is
totally stuck. The screen is properly updated on the other hand, this
proves the program doesn’t crash. As others fb applications does work
properly, I think the bug isn’t related to the framebuffer code (unless
there are different ways to get the input from the fb console).
Hmm. Okay. I’ll look at it again later today. If nothing else, it’s broken
somewhat recently.
–ryan.
My SDL version is 1.2.2, I don’t use the CVS code. My video card is a
Voodoo 3 - this may help as I’ve seen several source files related to
different video cards (including voodoo 3) in SDL’s fbcon driver
directory. Maybe this bug only happens on Voodoo 3 at all.
Alex.On 24 Aug 2001 07:06:20 -0400, Ryan C. Gordon wrote:
Actually, I don’t even get the key events in the program loop. That is,
even with SDL_Quit, I CAN’T quit the program because the keyboard is
totally stuck. The screen is properly updated on the other hand, this
proves the program doesn’t crash. As others fb applications does work
properly, I think the bug isn’t related to the framebuffer code (unless
there are different ways to get the input from the fb console).Hmm. Okay. I’ll look at it again later today. If nothing else, it’s broken
somewhat recently.
on 8/24/01 4:28 AM, Alexandre Courbot at alexandrecourbot at linuxgames.com
wrote:> On 23 Aug 2001 13:33:13 -0400, John R. Hall wrote:
I’ve had problems with reading the keyboard under the framebuffer console,
but I don’t recall the exact situation. There may well be a bug in SDL’s
keyboard code. To slightly twist a Linus Torvalds quote, Linux console
programming can be used to frighten small children…Hello everybody,
I face similar problems. When I use the fbcon target video and audio are
processed correctly. But input (keyboard/mouse) doesn’t work at all,
even console switching or kernel SysReq keys. Others applications that
use framebuffer seems to work though (I’ve been successfull with mplayer
at least), so this may be a bug in SDL input code? I’m using SDL 1.2.2
on a Linux 2.4.2 kernel with a Voodoo 3 card.
Mouse support is likely to fail; SDL has direct protocol support for several
common mouse devices, and falls back on GPM for the rest, if I recall. The
former will fail if GPM is already active, and the latter depends on having
GPM configured in a very specific way, which I at least did not. It’s been a
while since I looked at that code, so again, I could be totally off.
Keyboard support should not be a problem. Although the interface is ugly,
it’s not all that error prone. I was having some bizarre problem like two of
the four arrow keys not working. The problem may have gone away with a newer
release of SDL. I’ll check once my Linux box is back up.
-John