From: Ragnvald "Despair" Maartmann-Moe IV
Subject: SDL x11 video mode selection bug
Hi, I've found an oddity with video mode selection. I recently added a bunch of
oddball video modes to my XF86Config, to support weird resolutions xine &
mplayer need if I don't want to beat my cpu up with video scaling.
Since adding them, SDL started picking the biggest video mode it could find
that matched the height constraint. Getting a narrow vertical strip of
QuakeForge (I code for the project, so needless to say it's my favorite test)
in the middle of an 800x480 screen, instead of the 640x480 I asked for
annoys me tremendously.
So here's a patch that tries a bit harder to get an exact match. I didn't
touch the XiG section, since I can't test that, but I'd bet a similar patch
would prevent similar problems there.
--Ragnvald "Despair" Maartmann-Moe IV
--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%40605
Subject: testoverlay...
here's a fun one:
./testoverlay -scale -h
it seems to print argv[optind-1] as the program name...
--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%40604
From: Patrice Mandin
Subject: [SDL] Small patches for SDL
- One for SDL, which removes check for SDL_VIDEODRIVER in the Atari video
drivers. It is unnecessary 'cause it is done in SDL_video.c
--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%40594
From: "Mike Gorchak"
Subject: All QNX patches
whole patches concerning QNX. Almost all code has been rewritten by Julian
and me. Added initial support for hw overlays in QNX and many many others
fixes.
P.S. This patches has been reviewed by Dave Rempel from QSSL and included in
SDL 1.2.5 distribution, which coming on 3rd party CD for newest 6.2.1
version of QNX, which will be available soon.
--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%40572
From: "Mike Gorchak"
added support for checking libtool's version of libdl for dlopen.
--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%40571
From: "Mike Gorchak"
added help and options -mono to force monochrome RGB2YUB conversion and
-lum <percent> - luminance of image during conversion. Also rewritten code
which moves overlay into window. Now it depends on window size.
Also fully rewritten -scale option, image now scaling from 50% from center
of screen until border of window is reached - it really tests scaler, old
-scale test doesn't test downscale.
--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%40570
From: "Mike Gorchak"
added showing of type of the track, when adding -list arg
--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%40569
Subject: Qtopia patches (input grabbing and iconify)
Ok, here's a patch that adds support for SDL_WM_GrabInput (default
state is "ungrabbed") and SDL_WM_IconifyWindow. Also has some other
tweaks such as taking additional steps to clean up when exiting
(bypassing certain bugs in some versions of Qtopia and/or OPIE) and it
also maps Key_F33 to Key_Return (this is the Zaurus 'ok' key).
--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%40568
Enclosed is a patch that addresses the following:
--Various minor cleanups.
Removed dead/obsolete code, made some style cleanups
--Mouse Events
Now keep track of what button(s) were pressed so we know when to send
the mouse up event. This fixes the case where the mouse is dragged
outside of the game window and released (in which case we want to send
the mouse up event even though the mouse is outside the game window).
--Input Grabbing
Here is my take on the grabbing situation, which is the basis for the
new implementation.
There are 3 grab states, ungrabbed (UG), visible (VG), and invisible
(IG). Both VG and IG keep the mouse constrained to the window and
produce relative motion events. In VG the cursor is visible (duh), in
IG it is not. In VG, absolute motion events also work.
There are 6 actions that can affect grabbing:
1. Set Fullscreen/Window (F/W). In fullscreen, a visible grab should do
nothing. However, a fullscreen visible grab can be treated just like a
windowed visible grab, which is what I have done to help simplify
things.
2. Cursor hide/show (H/S). If the cursor is hidden when grabbing, the
grab is an invisible grab. If the cursor is visible, the grab should
just constrain the mouse to the window.
3. Input grab/ungrab(G/U). If grabbed, the cursor should be confined to
the window as should the keyboard input. On Mac OS X, the keyboard
input is implicitly grabbed by confining the cursor, except for
command-tab which can switch away from the application. Should the
window come to the foreground if the application is deactivated and
grab input is called? This isn't necessary in this implementation
because the grab state will be asserted upon activation.
Using my notation, these are all the cases that need to be handled
(state + action = new state).
UG+U = UG
UG+G = VG or IG, if cursor is visible or not
UG+H = UG
UG+S = UG
VG+U = UG
VG+G = VG
VG+H = IG
VG+S = VG
IG+U = UG
IG+G = IG
IG+H = IG
IG+S = VG
The cases that result in the same state can be ignored in the code,
which cuts it down to just 5 cases.
Another issue is what happens when the app loses/gains input focus from
deactivate/activate or iconify/deiconify. I think that if input focus
is ever lost (outside of SDL's control), the grab state should be
suspended and the cursor should become visible and active again. When
regained, the cursor should reappear in its original location and/or
grab state. This way, when reactivating the cursor is still in the same
position as before so apps shouldn't get confused when the next motion
event comes in. This is what I've done in this patch.
--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%40564
From: Darrell Walisser
Subject: Re: crash in SDL / OSX
> Yes, compose keys and other "dead" keys should have unicode 0.
> As a hack, if you get multiple composed characters, you can send the
> sequence with a valid unicode and a keysym of 0. It's because of
> things like this that I'm separating the key and char events in SDL 2.0
I've done this and here's the patch.
--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%40562