Re: [dev] dwm: bug in fullscreen mode (SDL?)
On Wed, 7 Mar 2012 00:31:12 +0100 Swiatoslaw Gal wrote: >-- From Matthew Carter 23-01-2012 at 22:01 -- >> You could always run fullscreen apps/games on a separate X display >> using: >> >> xinit $(which gameName) -- :8 >> >> -Matt > >Can one use such a clean solution with a second display? >E.g. an external monitor attached to a laptop? > >s. > `man xorg.conf` or http://linux.die.net/man/5/xorg.conf - section ServerLayout. xinit $(which gameName -- :8 -layout "Your Layout Name"
Re: [dev] dwm: bug in fullscreen mode (SDL?)
-- From Matthew Carter 23-01-2012 at 22:01 -- > You could always run fullscreen apps/games on a separate X display > using: > > xinit $(which gameName) -- :8 > > -Matt Can one use such a clean solution with a second display? E.g. an external monitor attached to a laptop? s.
Re: [dev] dwm: bug in fullscreen mode (SDL?)
You could always run fullscreen apps/games on a separate X display using: xinit $(which gameName) -- :8 -Matt On Mon, Jan 23, 2012 at 02:14:40PM -0800, mikshaw wrote: > > > - Original Message - > > From: Roman Z. < > > Sent: Tuesday, January 10, 2012 5:54 PM > > Subject: Re: [dev] dwm: bug in fullscreen mode (SDL?) > > > > Games work when the screen resolution of the game is the same as the > > resolution in dwm. If the resolution is different, all I get is a black > > screen with the DWM statusbar at the top. Keyboard input is still > > passed to the game though. > > > > Running "wmname LG3D" doesn't change anything about this for me. > > > > Roman > > > > I've seen this happen frequently in the few games I play, and my solution has > been to open the game in windowed mode and switch to fullscreen inside the > game. It seems to be reliable. > > -- Matthew Carter jeh...@gmail.com
Re: [dev] dwm: bug in fullscreen mode (SDL?)
- Original Message - > From: Roman Z. < > Sent: Tuesday, January 10, 2012 5:54 PM > Subject: Re: [dev] dwm: bug in fullscreen mode (SDL?) > > Games work when the screen resolution of the game is the same as the > resolution in dwm. If the resolution is different, all I get is a black > screen with the DWM statusbar at the top. Keyboard input is still > passed to the game though. > > Running "wmname LG3D" doesn't change anything about this for me. > > Roman > I've seen this happen frequently in the few games I play, and my solution has been to open the game in windowed mode and switch to fullscreen inside the game. It seems to be reliable.
Re: [dev] dwm: bug in fullscreen mode (SDL?)
> I just want to mention this breaks raising my floating windows also. > Reverting the lines from the patch: > > - if(m->sel->isfloating || !m->lt[m->sellt]->arrange) > - XRaiseWindow(dpy, m->sel->win); > > seems to fix it again. That's why I attacked the SDL problem from another angle. The patch from my privious mail[1] should fix this and the SDL problem. [1] http://lists.suckless.org/dev/1201/10607.html -- Eckehard Berns
Re: [dev] dwm: bug in fullscreen mode (SDL?)
On Mon, Jan 16, 2012 at 12:25 AM, Anthony Cox wrote: > This seems to have broken my floating windows - if I have a floating XTerm > and open a new XTerm (tiled), the floating XTerm ends up behind the tiled > one and I can no longer raise the floating one above. > I just want to mention this breaks raising my floating windows also. Reverting the lines from the patch: - if(m->sel->isfloating || !m->lt[m->sellt]->arrange) - XRaiseWindow(dpy, m->sel->win); seems to fix it again. Kind regards, Hiltjo
Re: [dev] dwm: bug in fullscreen mode (SDL?)
On 16/01/12 01:20 ;+0100, Eckehard Berns wrote: The confnotify-tip.patch from my previous mail[1] should fix this hopefully. Yes, that seems to fix the floating issues - I can't comment on the original SDL issues however as I have not experienced them. -- Anthony Cox
Re: [dev] dwm: bug in fullscreen mode (SDL?)
> This seems to have broken my floating windows - if I have a floating > XTerm and open a new XTerm (tiled), the floating XTerm ends up > behind the tiled one and I can no longer raise the floating one > above. > > Another thing which seems to have been lost is the "feature" of > clicking a floating window raises it to the top; I use this a lot as > I unfortunately find myself using The GIMP regularly at work. The confnotify-tip.patch from my previous mail[1] should fix this hopefully. [1] http://lists.suckless.org/dev/1201/10607.html -- Eckehard Berns
Re: [dev] dwm: bug in fullscreen mode (SDL?)
On 12/01/12 07:39 ;+0100, Anselm R Garbe wrote: I applied your two patches to tip, this needs to be tested for side effects now. This seems to have broken my floating windows - if I have a floating XTerm and open a new XTerm (tiled), the floating XTerm ends up behind the tiled one and I can no longer raise the floating one above. Another thing which seems to have been lost is the "feature" of clicking a floating window raises it to the top; I use this a lot as I unfortunately find myself using The GIMP regularly at work. -- Anthony Cox
Re: [dev] dwm: bug in fullscreen mode (SDL?)
On Sat, Jan 14, 2012 at 12:41:51PM +0100, Eckehard Berns wrote:
> If no problems show up I think this is a better way of dealing with the
> SDL problem.
>
> --
> Eckehard Berns
>
> diff -r 070112b7435f dwm.c
> --- a/dwm.c Thu Jan 12 07:36:05 2012 +0100
> +++ b/dwm.c Sat Jan 14 12:34:59 2012 +0100
> @@ -397,9 +397,10 @@
> showhide(m->stack);
> else for(m = mons; m; m = m->next)
> showhide(m->stack);
> - if(m)
> + if(m) {
> arrangemon(m);
> - else for(m = mons; m; m = m->next)
> + restack(m);
> + } else for(m = mons; m; m = m->next)
> arrangemon(m);
> }
>
> @@ -408,7 +409,6 @@
> strncpy(m->ltsymbol, m->lt[m->sellt]->symbol, sizeof m->ltsymbol);
> if(m->lt[m->sellt]->arrange)
> m->lt[m->sellt]->arrange(m);
> - restack(m);
> }
>
> void
> @@ -1420,6 +1420,8 @@
> drawbar(m);
> if(!m->sel)
> return;
> + if(m->sel->isfloating || !m->lt[m->sellt]->arrange)
> + XRaiseWindow(dpy, m->sel->win);
> if(m->lt[m->sellt]->arrange) {
> wc.stack_mode = Below;
> wc.sibling = m->barwin;
correction to the aforementioned wireshark issue: this patch works for me,
except I don't need it any more since I have a workspace for it now.
+1 for the patch.
could we apply this to tip, soon?
cheers!
mar77i
Re: [dev] dwm: bug in fullscreen mode (SDL?)
On Thu, Jan 12, 2012 at 07:39:53AM +0100, Anselm R Garbe wrote: > I believe these two lines relate from an earlier algorithm that was > used prior to the barwin restacking. > > I applied your two patches to tip, this needs to be tested for side effects > now. > Well, currently wireshark is the only tool I found that works in a strange way and in the new dwm-tip after togglefloating it ends up underneath the tiling layer. I've not looked deeper into the issue except that 1592:6f54bd1ef439 currently works as expected for this software. cheers! mar77i
Re: [dev] dwm: bug in fullscreen mode (SDL?)
> I attached a somewhat ugly patch to correct the behavior, [...]
Since I didn't like how this patch turned out I looked into this a bit
further. Attached is a less intrusive patch, once to tip and once to
6.0. I ran this patch for a day or so and didn't have any issues.
If no problems show up I think this is a better way of dealing with the
SDL problem.
--
Eckehard Berns
diff -r 070112b7435f dwm.c
--- a/dwm.c Thu Jan 12 07:36:05 2012 +0100
+++ b/dwm.c Sat Jan 14 12:34:59 2012 +0100
@@ -397,9 +397,10 @@
showhide(m->stack);
else for(m = mons; m; m = m->next)
showhide(m->stack);
- if(m)
+ if(m) {
arrangemon(m);
- else for(m = mons; m; m = m->next)
+ restack(m);
+ } else for(m = mons; m; m = m->next)
arrangemon(m);
}
@@ -408,7 +409,6 @@
strncpy(m->ltsymbol, m->lt[m->sellt]->symbol, sizeof m->ltsymbol);
if(m->lt[m->sellt]->arrange)
m->lt[m->sellt]->arrange(m);
- restack(m);
}
void
@@ -1420,6 +1420,8 @@
drawbar(m);
if(!m->sel)
return;
+ if(m->sel->isfloating || !m->lt[m->sellt]->arrange)
+ XRaiseWindow(dpy, m->sel->win);
if(m->lt[m->sellt]->arrange) {
wc.stack_mode = Below;
wc.sibling = m->barwin;
diff -r ec4baab78314 dwm.c
--- a/dwm.c Mon Dec 19 15:38:30 2011 +0100
+++ b/dwm.c Sat Jan 14 12:35:50 2012 +0100
@@ -397,9 +397,10 @@
showhide(m->stack);
else for(m = mons; m; m = m->next)
showhide(m->stack);
- if(m)
+ if(m) {
arrangemon(m);
- else for(m = mons; m; m = m->next)
+ restack(m);
+ } else for(m = mons; m; m = m->next)
arrangemon(m);
}
@@ -408,7 +409,6 @@
strncpy(m->ltsymbol, m->lt[m->sellt]->symbol, sizeof m->ltsymbol);
if(m->lt[m->sellt]->arrange)
m->lt[m->sellt]->arrange(m);
- restack(m);
}
void
@@ -1827,6 +1827,8 @@
.event_mask = ButtonPressMask|ExposureMask
};
for(m = mons; m; m = m->next) {
+ if (m->barwin)
+ continue;
m->barwin = XCreateWindow(dpy, root, m->wx, m->by, m->ww, bh,
0, DefaultDepth(dpy, screen),
CopyFromParent, DefaultVisual(dpy,
screen),
CWOverrideRedirect|CWBackPixmap|CWEventMask, &wa);
Re: [dev] dwm: bug in fullscreen mode (SDL?)
Eckehard Berns wrote: > Sorry for spamming the list, but I didn't catch monocle mode with the > last patch. Here is a corrected patch... > > -- > Eckehard Berns work in combination with "barwin-leak.patch" no-raise-float-in-restack.patch work too. dwm-6.0 + SDL-1.2.14 clean
Re: [dev] dwm: bug in fullscreen mode (SDL?)
Sorry for spamming the list, but I didn't catch monocle mode with the
last patch. Here is a corrected patch...
--
Eckehard Berns
diff -r 070112b7435f dwm.c
--- a/dwm.c Thu Jan 12 07:36:05 2012 +0100
+++ b/dwm.c Thu Jan 12 23:56:15 2012 +0100
@@ -907,6 +907,8 @@
}
if(c) {
focus(c);
+ if (selmon->sel->isfloating ||
!selmon->lt[selmon->sellt]->arrange)
+ XRaiseWindow(dpy, selmon->sel->win);
restack(selmon);
}
}
@@ -1227,7 +1229,7 @@
if(!(c = selmon->sel))
return;
- restack(selmon);
+ XRaiseWindow(dpy, selmon->sel->win);
ocx = c->x;
ocy = c->y;
if(XGrabPointer(dpy, root, False, MOUSEMASK, GrabModeAsync,
GrabModeAsync,
@@ -1371,7 +1373,7 @@
if(!(c = selmon->sel))
return;
- restack(selmon);
+ XRaiseWindow(dpy, selmon->sel->win);
ocx = c->x;
ocy = c->y;
if(XGrabPointer(dpy, root, False, MOUSEMASK, GrabModeAsync,
GrabModeAsync,
@@ -1738,9 +1740,11 @@
if(!selmon->sel)
return;
selmon->sel->isfloating = !selmon->sel->isfloating ||
selmon->sel->isfixed;
- if(selmon->sel->isfloating)
+ if(selmon->sel->isfloating) {
resize(selmon->sel, selmon->sel->x, selmon->sel->y,
selmon->sel->w, selmon->sel->h, False);
+ XRaiseWindow(dpy, selmon->sel->win);
+ }
arrange(selmon);
}
Re: [dev] dwm: bug in fullscreen mode (SDL?)
On Thu, Jan 12, 2012 at 10:23:14PM +0100, Eckehard Berns wrote:
> I attached a somewhat ugly patch to correct the behavior, ...
Oops, we need raising in focusstack() not only for floating windows, but
also if we're in a floating layout. Corrected patch is attached.
--
Eckehard Berns
diff -r 070112b7435f dwm.c
--- a/dwm.c Thu Jan 12 07:36:05 2012 +0100
+++ b/dwm.c Thu Jan 12 22:27:51 2012 +0100
@@ -907,7 +907,8 @@
}
if(c) {
focus(c);
- restack(selmon);
+ if (selmon->sel->isfloating ||
!selmon->lt[selmon->sellt]->arrange)
+ XRaiseWindow(dpy, selmon->sel->win);
}
}
@@ -1227,7 +1228,7 @@
if(!(c = selmon->sel))
return;
- restack(selmon);
+ XRaiseWindow(dpy, selmon->sel->win);
ocx = c->x;
ocy = c->y;
if(XGrabPointer(dpy, root, False, MOUSEMASK, GrabModeAsync,
GrabModeAsync,
@@ -1371,7 +1372,7 @@
if(!(c = selmon->sel))
return;
- restack(selmon);
+ XRaiseWindow(dpy, selmon->sel->win);
ocx = c->x;
ocy = c->y;
if(XGrabPointer(dpy, root, False, MOUSEMASK, GrabModeAsync,
GrabModeAsync,
@@ -1738,9 +1739,11 @@
if(!selmon->sel)
return;
selmon->sel->isfloating = !selmon->sel->isfloating ||
selmon->sel->isfixed;
- if(selmon->sel->isfloating)
+ if(selmon->sel->isfloating) {
resize(selmon->sel, selmon->sel->x, selmon->sel->y,
selmon->sel->w, selmon->sel->h, False);
+ XRaiseWindow(dpy, selmon->sel->win);
+ }
arrange(selmon);
}
Re: [dev] dwm: bug in fullscreen mode (SDL?)
On Thu, Jan 12, 2012 at 07:39:53AM +0100, Anselm R Garbe wrote:
> I applied your two patches to tip, this needs to be tested for side effects
> now.
Ok, I ran into trouble pretty fast. Since the floating windows are never
raised in restack() they won't get raised during normal interaction
either.
I attached a somewhat ugly patch to correct the behavior, but there
might be consequences, too. Instead of simply adding XRaiseWindow() I
replaced calls to restack() in focusstack(), movemouse(), and
resizemouse(). I assume restacking isn't needed there and the calls to
restack() simple where a glorified XRaiseWindow() anyway, but I'm not
too familiar with the dwm code, so I might be wrong.
--
Eckehard Berns
diff -r 070112b7435f dwm.c
--- a/dwm.c Thu Jan 12 07:36:05 2012 +0100
+++ b/dwm.c Thu Jan 12 22:07:34 2012 +0100
@@ -907,7 +907,8 @@
}
if(c) {
focus(c);
- restack(selmon);
+ if (selmon->sel->isfloating)
+ XRaiseWindow(dpy, selmon->sel->win);
}
}
@@ -1227,7 +1228,7 @@
if(!(c = selmon->sel))
return;
- restack(selmon);
+ XRaiseWindow(dpy, selmon->sel->win);
ocx = c->x;
ocy = c->y;
if(XGrabPointer(dpy, root, False, MOUSEMASK, GrabModeAsync,
GrabModeAsync,
@@ -1371,7 +1372,7 @@
if(!(c = selmon->sel))
return;
- restack(selmon);
+ XRaiseWindow(dpy, selmon->sel->win);
ocx = c->x;
ocy = c->y;
if(XGrabPointer(dpy, root, False, MOUSEMASK, GrabModeAsync,
GrabModeAsync,
@@ -1738,9 +1739,11 @@
if(!selmon->sel)
return;
selmon->sel->isfloating = !selmon->sel->isfloating ||
selmon->sel->isfixed;
- if(selmon->sel->isfloating)
+ if(selmon->sel->isfloating) {
resize(selmon->sel, selmon->sel->x, selmon->sel->y,
selmon->sel->w, selmon->sel->h, False);
+ XRaiseWindow(dpy, selmon->sel->win);
+ }
arrange(selmon);
}
Re: [dev] dwm: bug in fullscreen mode (SDL?)
On 11 January 2012 22:47, Eckehard Berns wrote: > On Wed, Jan 11, 2012 at 10:20:43PM +0100, Anselm R Garbe wrote: >> On 11 January 2012 18:30, Eckehard Berns wrote: >> > Thinking about this, another way to fix this problem would be to >> > change all XRaiseWindow calls in dwm to restacking them just below the >> > bar and never raising the bar. That way dwm would play nicely with other >> > override redirect windows as well. I don't know if that would be worth >> > it. >> >> I need to try this, as this sounds like a sensible way to fix this >> issue. If it does, then I have no objection putting this into mainline >> dwm. > > I thought a bit more about this and I don't think the solution is so > easy. I'd assume that you don't want every override redirect window to > be always on top. Also, floating windows are above the bar at the > moment, which is what you would expect IMHO. That means that there is no > suitable window to align the stacking of floating windows to. > > And as it seems, the floating WMwindow of SDL is the main problem here. > > On a related note, while investigating the SDL-problem further I found a > leak in dwm: updatebars() always creates new barwins. I attached a patch > to skip the creation of a new barwin if the monitor already has one. > This is why I thought the barwin would be raised, but instead a new one > is created (which has the same effect). > > What remains is the floating WMwindow which will be raised in restack(). > Does anyone remember why the code in lines 1423 and 1424 is neccessary? > Without it the SDL problem doesn't occure on my system any more (without > the need to patch SDL itself). I attached the second patch for anyone > who wants to try this. I believe these two lines relate from an earlier algorithm that was used prior to the barwin restacking. I applied your two patches to tip, this needs to be tested for side effects now. Thanks for your valuable contribution Eckehard! Cheers, Anselm
Re: [dev] dwm: bug in fullscreen mode (SDL?)
Eckehard Berns wrote: > It seems that the problem isn't the reparenting stuff. The attached > patch for SDL-1.2.14 worked for me. > > If anyone is interested, here is what happens: > > SDL creates two windows: FSwindow and WMwindow. FSwindow has the > override redirect flag set, and WMwindow is ment to be managed by the wm > for windowed mode. The actual drawing happens in SDL_Window. In windowed > mode the SDL_Window is a child of WMwindow. As soon as the app requests > full screen mode the SDL_Window is reparented into the FSwindow which > then stretches the whole screen. > > The problem is that the WMwindow is also created and managed by dwm. As > soon as the screen resolution is changed, dwm raises the bar and restacks > all tiled windows (including the empty - thus black) WMwindow just below > the bar. Now all managed windows are above the FSwindow. This also > explains why full screen mode works when the resolution doesn't change, > since then the stacking order of the windows stays and FSwindow is still > on top. > > Thinking about this, another way to fix this problem would be to > change all XRaiseWindow calls in dwm to restacking them just below the > bar and never raising the bar. That way dwm would play nicely with other > override redirect windows as well. I don't know if that would be worth > it. > > -- > Eckehard Berns thank you very much! patch work for me too :)
Re: [dev] dwm: bug in fullscreen mode (SDL?)
On Wed, Jan 11, 2012 at 10:20:43PM +0100, Anselm R Garbe wrote:
> On 11 January 2012 18:30, Eckehard Berns wrote:
> > Thinking about this, another way to fix this problem would be to
> > change all XRaiseWindow calls in dwm to restacking them just below the
> > bar and never raising the bar. That way dwm would play nicely with other
> > override redirect windows as well. I don't know if that would be worth
> > it.
>
> I need to try this, as this sounds like a sensible way to fix this
> issue. If it does, then I have no objection putting this into mainline
> dwm.
I thought a bit more about this and I don't think the solution is so
easy. I'd assume that you don't want every override redirect window to
be always on top. Also, floating windows are above the bar at the
moment, which is what you would expect IMHO. That means that there is no
suitable window to align the stacking of floating windows to.
And as it seems, the floating WMwindow of SDL is the main problem here.
On a related note, while investigating the SDL-problem further I found a
leak in dwm: updatebars() always creates new barwins. I attached a patch
to skip the creation of a new barwin if the monitor already has one.
This is why I thought the barwin would be raised, but instead a new one
is created (which has the same effect).
What remains is the floating WMwindow which will be raised in restack().
Does anyone remember why the code in lines 1423 and 1424 is neccessary?
Without it the SDL problem doesn't occure on my system any more (without
the need to patch SDL itself). I attached the second patch for anyone
who wants to try this.
--
Eckehard Berns
diff -r 6f54bd1ef439 dwm.c
--- a/dwm.c Wed Jan 04 13:30:12 2012 +0100
+++ b/dwm.c Wed Jan 11 22:29:57 2012 +0100
@@ -1827,6 +1827,8 @@
.event_mask = ButtonPressMask|ExposureMask
};
for(m = mons; m; m = m->next) {
+ if (m->barwin)
+ continue;
m->barwin = XCreateWindow(dpy, root, m->wx, m->by, m->ww, bh,
0, DefaultDepth(dpy, screen),
CopyFromParent, DefaultVisual(dpy,
screen),
CWOverrideRedirect|CWBackPixmap|CWEventMask, &wa);
diff -r 6f54bd1ef439 dwm.c
--- a/dwm.c Wed Jan 04 13:30:12 2012 +0100
+++ b/dwm.c Wed Jan 11 22:35:27 2012 +0100
@@ -1420,8 +1420,6 @@
drawbar(m);
if(!m->sel)
return;
- if(m->sel->isfloating || !m->lt[m->sellt]->arrange)
- XRaiseWindow(dpy, m->sel->win);
if(m->lt[m->sellt]->arrange) {
wc.stack_mode = Below;
wc.sibling = m->barwin;
Re: [dev] dwm: bug in fullscreen mode (SDL?)
Quoth Eckehard Berns: > At work I'm on a 32-bit system, here I'm on 64-bit. I'm on a 32-bit x86 here, where it works fine, FWIW. pgp3wvMtlMBZR.pgp Description: PGP signature
Re: [dev] dwm: bug in fullscreen mode (SDL?)
On 11 January 2012 18:30, Eckehard Berns wrote: > Thinking about this, another way to fix this problem would be to > change all XRaiseWindow calls in dwm to restacking them just below the > bar and never raising the bar. That way dwm would play nicely with other > override redirect windows as well. I don't know if that would be worth > it. I need to try this, as this sounds like a sensible way to fix this issue. If it does, then I have no objection putting this into mainline dwm. Cheers, Anselm
Re: [dev] dwm: bug in fullscreen mode (SDL?)
> It seems like sensible behavior to go into mainline SDL; any reason > not to send this patch their way? I just tried the patch at home and it doesn't work. I also reviewed dwm's source code and my memory of the bar being risen was a bit faulty. I still think the stacking order is the problem here, but it seems my solution isn't the best. At work I'm on a 32-bit system, here I'm on 64-bit. I don't know if this makes any difference or if there is another problem. It might be a race condition between the XRaiseWindow in SDL and the receiving of the screen resize event in dwm. -- Eckehard Berns
Re: [dev] dwm: bug in fullscreen mode (SDL?)
Quoth Eckehard Berns: > It seems that the problem isn't the reparenting stuff. The attached > patch for SDL-1.2.14 worked for me. Thanks for looking into this and providing the patch - it works great for me. It seems like sensible behavior to go into mainline SDL; any reason not to send this patch their way? Nick P.S. I applied this patch to SDL in my Gentoo repository, if anyone wants to just use that. 'njw' in layman. pgp9jtxwRlfv1.pgp Description: PGP signature
Re: [dev] dwm: bug in fullscreen mode (SDL?)
It seems that the problem isn't the reparenting stuff. The attached patch for SDL-1.2.14 worked for me. If anyone is interested, here is what happens: SDL creates two windows: FSwindow and WMwindow. FSwindow has the override redirect flag set, and WMwindow is ment to be managed by the wm for windowed mode. The actual drawing happens in SDL_Window. In windowed mode the SDL_Window is a child of WMwindow. As soon as the app requests full screen mode the SDL_Window is reparented into the FSwindow which then stretches the whole screen. The problem is that the WMwindow is also created and managed by dwm. As soon as the screen resolution is changed, dwm raises the bar and restacks all tiled windows (including the empty - thus black) WMwindow just below the bar. Now all managed windows are above the FSwindow. This also explains why full screen mode works when the resolution doesn't change, since then the stacking order of the windows stays and FSwindow is still on top. Thinking about this, another way to fix this problem would be to change all XRaiseWindow calls in dwm to restacking them just below the bar and never raising the bar. That way dwm would play nicely with other override redirect windows as well. I don't know if that would be worth it. -- Eckehard Berns --- SDL-1.2.14/src/video/x11/SDL_x11modes.c~2012-01-11 17:38:21.138611142 +0100 +++ SDL-1.2.14/src/video/x11/SDL_x11modes.c 2012-01-11 17:30:52.906622687 +0100 @@ -968,6 +968,7 @@ x = (real_w - window_w)/2; y = (real_h - window_h)/2; XReparentWindow(SDL_Display, SDL_Window, FSwindow, x, y); + XRaiseWindow(SDL_Display, FSwindow); /* FIXME: move the mouse to the old relative location */ XSync(SDL_Display, True); /* Flush spurious mode change events */ }
Re: [dev] dwm: bug in fullscreen mode (SDL?)
Hadrian Węgrzynowski wrote: > On Wed, 11 Jan 2012 12:35:09 +0500 > ∞ wrote: > > >On 1/11/12, Jakub Lach wrote: > >> http://lists.libsdl.org/pipermail/sdl-libsdl.org/2010-February/074856.html > >> > >> And nothing. > >> > > > > > >but, in openbox SDL-apps work fine. need patch for dwm or SDL? > > > > AFAIK openbox is reparenting wm. The problem is that SDL assumes > that all wms are reparenting. Which is not true in case of dwm. good. but dwm version 4.3 work fine with sdl in fullscreen mode. really it is impossible to correct it in current release?
Re: [dev] dwm: bug in fullscreen mode (SDL?)
On Wed, 11 Jan 2012 12:35:09 +0500 ∞ wrote: >On 1/11/12, Jakub Lach wrote: >> http://lists.libsdl.org/pipermail/sdl-libsdl.org/2010-February/074856.html >> >> And nothing. >> > > >but, in openbox SDL-apps work fine. need patch for dwm or SDL? > AFAIK openbox is reparenting wm. The problem is that SDL assumes that all wms are reparenting. Which is not true in case of dwm.
Re: [dev] dwm: bug in fullscreen mode (SDL?)
On 1/11/12, Jakub Lach wrote: > http://lists.libsdl.org/pipermail/sdl-libsdl.org/2010-February/074856.html > > And nothing. > but, in openbox SDL-apps work fine. need patch for dwm or SDL?
Re: [dev] dwm: bug in fullscreen mode (SDL?)
http://lists.libsdl.org/pipermail/sdl-libsdl.org/2010-February/074856.html And nothing.
Re: [dev] dwm: bug in fullscreen mode (SDL?)
Quoth Roman Z.: > Games work when the screen resolution of the game is the same as the > resolution in dwm. If the resolution is different, all I get is a black > screen with the DWM statusbar at the top. Keyboard input is still > passed to the game though. > > Running "wmname LG3D" doesn't change anything about this for me. Argh, you're right, I'm wrong. The games I tested all had their resolution set to my screen size, so worked anyway. I didn't realise this was only an issue when SDL changes the resolution. Sorry for the misinformation. The wmname trick doesn't work here. Somebody suitably masochistic should find and fix the offending code in SDL. pgpQI4GSRVHX0.pgp Description: PGP signature
Re: [dev] dwm: bug in fullscreen mode (SDL?)
On Tue, Jan 10, 2012 at 06:42:42PM +, Nick wrote:
> Quoth ∞:
> > i found bug in dwm-{5.9,6.0} version (and early too)
> > when open one of some application fullscreened - eg zsnes, dosbox,
> > vbam - in any layout mode screen blacking and nothing work. software
> > using SDL, may be in this reason? how to fix it?
> > in openbox that applications work good, but... i want using dwm, not
> > openbox! ))
>
> This is a known bug with SDL. It doesn't handle non-reparenting
> window managers properly. This bug was reported to them back in 2009
> I think (can't find it now), but hasn't gone anywhere.
>
> However, it turns out you can work around this using wmname
> http://tools.suckless.org/wmname to set the window manager name to
> 'LG3D'. This is the same fix which is needed to make some JDK
> programs work correctly. Thanks to Connor for suggesting it to me.
>
> Can someone with hg access update the BUGS file in the dwm
> repository with this workaround, please?
>
> So !g, install wmname, then add the line 'wmname LG3D' to your
> .xinitrc file above dwm, so it's executed every time X starts.
>
> Nick
Games work when the screen resolution of the game is the same as the
resolution in dwm. If the resolution is different, all I get is a black
screen with the DWM statusbar at the top. Keyboard input is still
passed to the game though.
Running "wmname LG3D" doesn't change anything about this for me.
Roman
Re: [dev] dwm: bug in fullscreen mode (SDL?)
Quoth ∞:
> i found bug in dwm-{5.9,6.0} version (and early too)
> when open one of some application fullscreened - eg zsnes, dosbox,
> vbam - in any layout mode screen blacking and nothing work. software
> using SDL, may be in this reason? how to fix it?
> in openbox that applications work good, but... i want using dwm, not openbox!
> ))
This is a known bug with SDL. It doesn't handle non-reparenting
window managers properly. This bug was reported to them back in 2009
I think (can't find it now), but hasn't gone anywhere.
However, it turns out you can work around this using wmname
http://tools.suckless.org/wmname to set the window manager name to
'LG3D'. This is the same fix which is needed to make some JDK
programs work correctly. Thanks to Connor for suggesting it to me.
Can someone with hg access update the BUGS file in the dwm
repository with this workaround, please?
So !g, install wmname, then add the line 'wmname LG3D' to your
.xinitrc file above dwm, so it's executed every time X starts.
Nick
pgpV7Y9fCO8Yo.pgp
Description: PGP signature
Re: [dev] dwm: bug in fullscreen mode (SDL?)
> i found bug in dwm-{5.9,6.0} version (and early too)
> when open one of some application fullscreened - eg zsnes, dosbox,
> vbam - in any layout mode screen blacking and nothing work.
I think I have seen something similar when starting ioquake3. At least
with ioquake3 I think the problem is that the software switches the
resolution. Dwm already checks for fullscreen apps with the current
screen size but might miss the apps that switch screen resolution.
I haven't looked into this. My workaround is that I start ioquake3 on a
new display (e.g. something like "startx `which ioquake3` -- :1").
--
Eckehard Berns
