Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

X11: Wrong initial size in tiling WM (+ solution?) #630

Closed
SDLBugzilla opened this issue Feb 10, 2021 · 0 comments
Closed

X11: Wrong initial size in tiling WM (+ solution?) #630

SDLBugzilla opened this issue Feb 10, 2021 · 0 comments
Labels
wontfix This will not be worked on

Comments

@SDLBugzilla
Copy link
Collaborator

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

Reported in version: 1.2.14
Reported for operating system, platform: Linux, x86

Comments on the original bug report:

On 2011-07-14 01:01:14 +0000, Tony Lainson wrote:

Created attachment 646
patch for X11_Wait(Un)Mapped

SDL 1.2 often fails to observe a resize event if it happens just as the window is being created. No SDL_VIDEORESIZE event is sent to the application. Any extra space remains black.

X11_WaitMapped() (in src/video/x11/SDL_x11modes.c) drops resize events that arrive before the window is mapped (StructureNotifyMask selects both MapNotify and ConfigureNotify events). I think that might be a problem if the window manager resizes the window before mapping it. Neither of the WMs I tried actually do that, but I've attached a patch anyway.

The real problem is in try_mitshm() (src/video/x11/SDL_x11image.c): XSync is called with the "discard" parameter set to True, which nukes everything in the event queue. Is there a reason for that? Would anything break if we changed it to False?

The XSync(blah, True) calls in other files look deliberate. They make me uneasy, but I don't know what (if anything) should be done about them. In any case, I haven't seen the resize bug since I changed True to False in try_mitshm().

I'm not at all familiar with SDL 1.3, but it looks like the only surviving problem is the XSync in the SHM code (which I haven't tried to trigger). Nice work!

On 2011-12-29 01:44:00 +0000, Sam Lantinga wrote:

I'm hesitant to change X11 behavior in SDL 1.2. Thanks for the patch though!

On 2012-06-21 02:43:05 +0000, driedfruit wrote:

Created attachment 883
Same patch, but for SDL2

Made against 6335:fbb84f5b985f

@SDLBugzilla SDLBugzilla added bug wontfix This will not be worked on labels Feb 10, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
wontfix This will not be worked on
Projects
None yet
Development

No branches or pull requests

1 participant