I noticed that SDL (1.2) is generating KEYDOWN events when it shouldn’t.
I’m using “icewm” window manager under Linux 2.2.19, XFree86 4.0.3. In this
window manager I have keybindings such that “Alt+Tab” cycles to next app,
while “Alt+” goes to desktop . If I tab out to another app,
and then back to an SDL one, SDL will erroneously generate a “Tab” KEYDOWN on
reentry. Another example: let’s say my SDL app is on desktop 1, I do "Alt+4"
to go to desktop 4, then do “Alt+1” to get back, SDL will generate a KEYDOWN
for “1”.
I ran “xev” and went throught the same sequence, and no such extra KEYDOWN
events were noted, so I don’t think it’s the window manager misguidedly
passing them down somehow.–
Maciej Kalisiak mac at dgp.toronto.eduwww.dgp.toronto.edu/~mac
I’m using “icewm” window manager under Linux 2.2.19, XFree86 4.0.3. In this
window manager I have keybindings such that “Alt+Tab” cycles to next app,
while “Alt+” goes to desktop . If I tab out to another app,
and then back to an SDL one, SDL will erroneously generate a “Tab” KEYDOWN on
reentry.
SDL keeps an internal map of which keys are currently pressed (this is
what you get with SDL_GetKetState). When your window loses focus, all
keys are considered released so synthetic KEYUP events are generated
where necessary. When it regains focus, SDL checks what keys are still
being held down, and generates synthetic KEYDOWN events for these,
so that the application won’t see sudden KEYUP events for keys that it
doesn’t think are being pressed
If this is undesirable we could change it so that keyup events for
non-pressed keys are ignored, but I prefer not changing too much
of the semantics in the 1.2 branch
I grab frames from video grabber card and show then out through
YUVOverlay. However, images are a little too dark [1] and afaik xvideo
supports changing brightness (and hue and contrast) of overlays
independent of gamma. Is there some undocumented (at least I couldn’t find
any documented one) function to do this via SDL? If not any suggestions
for a workaround? Should I guess video port [2] that’s in use and try to
change it’s settings?
I’m using SDL 1.2.0 with Linux 2.4.5/XFree 4.1.0 w/ Matrox G400.
Mikko
[1] Images are too dark when shown in screen. Gamma setting doesn’t affect
overlays and I need to tweek INPUT (for example increase values to get
dark shades instead of pure black) for overlay instead of OUTPUT that is
visible. This practically decreases usable bit depth and decreases image
quality.
[2] Yeah, I know that G400 only has one video port but in case that this
software is used in another system I’d want to do The Right Thing™.
SDL keeps an internal map of which keys are currently pressed (this is
what you get with SDL_GetKetState). When your window loses focus, all
keys are considered released so synthetic KEYUP events are generated
where necessary. When it regains focus, SDL checks what keys are still
being held down, and generates synthetic KEYDOWN events for these,
so that the application won’t see sudden KEYUP events for keys that it
doesn’t think are being pressed
Ahhhh. Hmm, well, it seems this way that if one causes an SDL application to
regain focus through some key combination, the app will always generate these
extra KEYDOWNs. Even on a Windows machine, if one Alt+Tabs to the
application, it sounds like the extra “Tab” will be generated. I would think
this would be a common occurrence then.
If this is undesirable we could change it so that keyup events for
non-pressed keys are ignored,
That would be great.
but I prefer not changing too much of the semantics in the 1.2 branch
In that case, could it perhaps be made somehow a runtime option? I’m thinking
of something like “SDL_Option(NO_KEYUPS_ON_LOSE_FOCUS)” or something of
similar intent. That way legacy SDL apps go on the way they were, while newer
apps have the choice of picking the functionality they want.On Thu, Jul 12, 2001 at 05:10:14AM -0400, Mattias EngdegUrd wrote:
You could adjust the data itself and add a certain
constant/percentage to every Y value (and cut it down
to 255 if necessary).
I’m not sure if that’s what you are looking for…
I’m using “icewm” window manager under Linux 2.2.19, XFree86 4.0.3. In this
window manager I have keybindings such that “Alt+Tab” cycles to next app,
while “Alt+” goes to desktop . If I tab out to another app,
and then back to an SDL one, SDL will erroneously generate a “Tab” KEYDOWN on
reentry.
SDL keeps an internal map of which keys are currently pressed (this is
what you get with SDL_GetKetState). When your window loses focus, all
keys are considered released so synthetic KEYUP events are generated
where necessary. When it regains focus, SDL checks what keys are still
being held down, and generates synthetic KEYDOWN events for these,
so that the application won’t see sudden KEYUP events for keys that it
doesn’t think are being pressed
If this is undesirable we could change it so that keyup events for
non-pressed keys are ignored, but I prefer not changing too much
of the semantics in the 1.2 branch
This behavior is actually breaking a bunch of applications (including
some Loki games), so I would like to revert back to the original behavior
of not generating synthetic keydowns after losing keyboard focus.
SDL should already ignore key up events for keys that it doesn’t think
are down. The original reason for this code was to keep the modifier
keys in sync, so that ctrl, numlock, etc. are in the correct state on
startup and also when regaining input focus.
Maybe we can do something different? Maybe just set the modifier state
when gaining input focus?
See ya,
-Sam Lantinga, Lead Programmer, Loki Software, Inc.
This behavior is actually breaking a bunch of applications (including
some Loki games), so I would like to revert back to the original behavior
of not generating synthetic keydowns after losing keyboard focus.
yes I’m convinced
Maybe we can do something different? Maybe just set the modifier state
when gaining input focus?
that’s probably the best thing to do. I’d also like to see if it’s
possible to generate keyup/keydown events for locking keys each time
they are toggled, instead of just handing out a keydown event when
it’s turned on, and a keyup event when it’s turned off. It also implies
that the locking keys should not have their modifier state in the
keystate vector but work as any other key if possible
This is exactly what I’m currently doing (I wasn’t exactly clear in in my
original posting; I used word INPUT when I meant “Y values written to YUV
overlay” and OUTPUT when I really meant “real intensity displayed on
screen”.). There are some problems though…
I’m missing some precision because I cannot use full 8 bit range of Y
values but instead like 30-255 [range of 0-30 would be all black anyway]
(this is minor problem because I’m using analog source that has enough
noise to cover some missed bits, but it can make difference when I add
some noise reduction code)
Even if I send 255 to overlay it won’t be as bright as 255,255,255 to
RGB surface. This is because overlay would require more brightness and
this cannot be fixed with adjust to input values.
Because this could be done with hardware through xvideo it’s a real
shame to need to fix it with CPU simply because SDL doesn’t have API for
this. Because I’m grabbing 768x576 25fps and doing some image processing
in real time I need every cycle I can get - ultimate target would be to
generate 50fps through intelligent deinterlacing routine but at least
currently it would take too much CPU power.
Also, middle range colors are too dark but I’d need gamma setting to fix
this because brightness and contrast are linear controls and cannot move
middle point of color ramp nearer to other end.
What I’m looking for is some way to really modify xvideo brightness and
contrast. If SDL doesn’t support this then I any suggestions about how to
do it without official support would be appreciated. I’m meaning
workarounds in spirit of GTK hack via environment variable.
It’s Friday night and English isn’t my native language but I hope you
understand what’s the problem…
MikkoOn Fri, 13 Jul 2001, Eike R. Sauer wrote:
If not any suggestions for a workaround?
You could adjust the data itself and add a certain
constant/percentage to every Y value (and cut it down
to 255 if necessary).
I’m not sure if that’s what you are looking for…
I grab frames from video grabber card and show then out through
YUVOverlay. However, images are a little too dark [1] and afaik xvideo
supports changing brightness (and hue and contrast) of overlays
independent of gamma. Is there some undocumented (at least I couldn’t find
any documented one) function to do this via SDL?
I don’t see an API to do this using XVideo. Am I missing something?
See ya,
-Sam Lantinga, Lead Programmer, Loki Software, Inc.
I grab frames from video grabber card and show then out through
YUVOverlay. However, images are a little too dark [1] and afaik xvideo
supports changing brightness (and hue and contrast) of overlays
independent of gamma. Is there some undocumented (at least I couldn’t find
any documented one) function to do this via SDL?
I don’t see an API to do this using XVideo. Am I missing something?
I don’t see an API to do this using XVideo. Am I missing something?
XvQueryPortAttributes, XvSetPortAttribute
Ahh, I didn’t know you could use this to set that.
Well, if you can write up an implementation that can set the brightness
for the YUV overlay that works with Linux XVideo, Windows DirectX, and
the SDL software code, then I’ll be happy to add it.
See ya!
-Sam Lantinga, Lead Programmer, Loki Software, Inc.
This behavior is actually breaking a bunch of applications (including
some Loki games), so I would like to revert back to the original behavior
of not generating synthetic keydowns after losing keyboard focus.
yes I’m convinced
Maybe we can do something different? Maybe just set the modifier state
when gaining input focus?
Okay, this is now implemented in CVS. The correct keyboard and modifier
state is set when the application starts up and when the keyboard focus
is gained. Changing how the capslock and numlock keys function will wait
until SDL 1.3
To sum up, you no longer get spurious key down events on X11.
I’m accepting patches that have similar functionality for the other
platforms, too.
See ya!
-Sam Lantinga, Lead Programmer, Loki Software, Inc.
