I've a 19" screen (1280x1024) and a 15,4" (1280x800) screen on my notebook and connected them together to a big screen with Xinerama. Everything works very great with Xfce besides one thing: I set up a screen edge on the lower end of my screen, so windows won't grow over my panel if I maximize them. It works great on the 19" screen, but it doesn't work on the smaller 15,4" screen. The window manager seems not to be aware, that the two screens have a different size. The edge exists, but it is outside the smaller screen (at the correct position of that edge on the bigger screen). However the panel is at the right position and even the desktop background image will be scaled correctly to the size of 1280x800. I don't know if it is hard to change this, but it would be nice for using Xinerama on screens with different sizes (e.g. like in my case: a notebook with an additional LCD). And I don't know if it is really a problem of the window manager, because this problem exists with other window managers, too.
Created attachment 1079 Test program Hi, can you build, run the attached program (instructions on how to compile the program are given at the beginning of the source file) and post the result here? Also, can you take a whole screenshot showing the problem (a visual example usually helps a lot) and attach it to this report? TIA Olivier.
Created attachment 1080 Screenshot showing windows snapping in on the wrong positions on the smaller screen
Created attachment 1081 Screenshot showing the wrong maximization of a window on the smaller screen
I got this output from your program: Current display has 1 screen(s) : - The screen #0 has 2 monitor(s) attached: * Screen #0, monitor #0, position (0, 0), size (1280, 800) * Screen #0, monitor #1, position (1280, 0), size (1280, 1024) I'm using the fglrx driver in Xinerama mode on a Xgl server. I don't know if it is a problem of Xfce or a problem of Xgl. However I got similar problems with other window managers (like Beryl) on Xfce, too. Other things (like streching the desktop background image or placing the panels) are done the right way.
Your panel is in "free move" mode right (the panel has handles on the screenshot, which proves it's freely movable)? The panel doesn't set struts in "freely movable" mode, that's why you get this result (ie this is perfectly normal behaviour) If you want the panel to set its struts, use the "fixed position" mode. This way, the panel will place itself on a screen and properly set is struts so that the window manager is aware of the area to keep uncovered. To set "fixed position mode" in the panel, right click on the panel, select "Customize panel" (last item in the menu) and set "Position" to "Fixed position". Then select on which monitor you want the panel to be placed. One last word, the use of the Xgl server is really a waste of resources with Xfce as it's not using OpenGL (unlike Beryl/Compiz, xfwm4 use Xrender, not OpenGL). So you'd better use the Xorg xserver.
"Your panel is in "free move" mode right (the panel has handles on the screenshot, which proves it's freely movable)?" The panel is not set to "free move" mode, it has a fixed position. "One last word, the use of the Xgl server is really a waste of resources with Xfce as it's not using OpenGL (unlike Beryl/Compiz, xfwm4 use Xrender, not OpenGL). So you'd better use the Xorg xserver." I know that XGL is not just a good solution, but because the fglrx driver doesn't support the composite extension on my video card I've to use XGL if I want to have a little eye candy on my desktop. I hope that the fglrx driver will get better in future, so it support compositing natively - but at moment it doesn't work with my Mobility x1400.
This problem exists also without Xgl, so it seems not to be an specific problem which is specific to Xgl.
(In reply to comment #7) > This problem exists also without Xgl, so it seems not to be an specific problem > which is specific to Xgl. Of course, it's not a XGL problem, I'm just saying that using XGL with Xfce will slow things down a lot, it's just a friendly, off topic advice.
Anyway, this is not a window manager bug, the panel is responsible for setting the struts correctly, not the window manager (and the problem shows in various window managers, so this confirms, if needed, that it's not a window manager issue) This bug is a duplicate of bug #1550 which is supposed to be fixed, according to the status. I'm reassigning this bug for further investigation on the panel side.
Hello Friedrich, could you post the output of the following two commands? xprop -root | grep WORKAREA xprop | grep STRUT After the second command you need to click on the panel. Olivier, this does look like a panel problem, but shouldn't the wm take the margins setting into account as well?
Okay, I got these results from "xprop -root | grep WORKAREA" _NET_SUPPORTED(ATOM) = _NET_ACTIVE_WINDOW, _NET_CLIENT_LIST, _NET_CLIENT_LIST_STACKING, _NET_CLOSE_WINDOW, _NET_CURRENT_DESKTOP, _NET_DESKTOP_GEOMETRY, _NET_DESKTOP_LAYOUT, _NET_DESKTOP_NAMES, _NET_DESKTOP_VIEWPORT, _NET_FRAME_EXTENTS, _NET_NUMBER_OF_DESKTOPS, _NET_REQUEST_FRAME_EXTENTS, _NET_SHOWING_DESKTOP, _NET_SUPPORTED, _NET_SUPPORTING_WM_CHECK, _NET_WM_ACTION_CHANGE_DESKTOP, _NET_WM_ACTION_CLOSE, _NET_WM_ACTION_MAXIMIZE_HORZ, _NET_WM_ACTION_MAXIMIZE_VERT, _NET_WM_ACTION_MOVE, _NET_WM_ACTION_RESIZE, _NET_WM_ACTION_SHADE, _NET_WM_ACTION_STICK, _NET_WM_ALLOWED_ACTIONS, _NET_WM_DESKTOP, _NET_WM_ICON, _NET_WM_ICON_GEOMETRY, _NET_WM_ICON_NAME, _NET_WM_MOVERESIZE, _NET_WM_NAME, _NET_WM_STATE, _NET_WM_STATE_ABOVE, _NET_WM_STATE_BELOW, _NET_WM_STATE_DEMANDS_ATTENTION, _NET_WM_STATE_FULLSCREEN, _NET_WM_STATE_HIDDEN, _NET_WM_STATE_MAXIMIZED_HORZ, _NET_WM_STATE_MAXIMIZED_VERT, _NET_WM_STATE_MODAL, _NET_WM_STATE_SHADED, _NET_WM_STATE_SKIP_PAGER, _NET_WM_STATE_SKIP_TASKBAR, _NET_WM_STATE_STICKY, _NET_WM_STRUT, _NET_WM_STRUT_PARTIAL, _NET_WM_SYNC_REQUEST, _NET_WM_SYNC_REQUEST_COUNTER, _NET_WM_USER_TIME, _NET_WM_WINDOW_TYPE, _NET_WM_WINDOW_TYPE_DESKTOP, _NET_WM_WINDOW_TYPE_DIALOG, _NET_WM_WINDOW_TYPE_DOCK, _NET_WM_WINDOW_TYPE_MENU, _NET_WM_WINDOW_TYPE_NORMAL, _NET_WM_WINDOW_TYPE_SPLASH, _NET_WM_WINDOW_TYPE_TOOLBAR, _NET_WM_WINDOW_TYPE_UTILITY, _NET_WORKAREA _NET_WORKAREA(CARDINAL) = 0, 0, 2560, 995, 0, 0, 2560, 995, 0, 0, 2560, 995, 0, 0, 2560, 995 If I apply "xprop | grep STRUT" to a panel of the smaller screen (the screen where windows got not maximized correctly), I got no result. If I apply the command to a panel on the bigger screen, I got this result: _NET_WM_STRUT(CARDINAL) = 0, 0, 0, 29 _NET_WM_STRUT_PARTIAL(CARDINAL) = 0, 0, 0, 29, 0, 0, 0, 0, 0, 0, 1280, 1498
(In reply to comment #11) ... > If I apply "xprop | grep STRUT" to a panel of the smaller screen (the screen > where windows got not maximized correctly), I got no result. > > If I apply the command to a panel on the bigger screen, I got this result: > > _NET_WM_STRUT(CARDINAL) = 0, 0, 0, 29 > _NET_WM_STRUT_PARTIAL(CARDINAL) = 0, 0, 0, 29, 0, 0, 0, 0, 0, 0, 1280, 1498 > Thanks. That is very helpful. Apparently, the panel thinks it cannot set the strut value on the small screen. Usually this would happen if the panel is freely movable, or if the layout of the screens is such that there is another screen below the screen the panel is on. Both do not seem to be the case, so I guess I'm having trouble with my math once again... I need to have a closer look at the code.
I don't know if it is helpful to you: but could it also be a bug of the ATI graphics driver? (Because this thing is known to be buggy...) (I can't test it with the free ATI driver, because it is not compatible with my graphics adapter)
(In reply to comment #13) > I don't know if it is helpful to you: but could it also be a bug of the ATI > graphics driver? (Because this thing is known to be buggy...) > > (I can't test it with the free ATI driver, because it is not compatible with my > graphics adapter) > No, that can't really be it. Olivier's test program shows that gtk recognizes the monitors properly. It's probably me, but I haven't found the cause yet.
Friedrich, I think I found the problem. It would be great if you could compile the panel with my proposed fix to see if it works. You can either use this patch: http://www.loculus.nl/xfce/files/panel-strut.patch . Or you could download the full sources: http://mocha.xfce.org/archive/test/xfce4-panel-4.4.1svn-25711.tar.bz2
Okay, it works great! Thank you.
(In reply to comment #16) > Okay, it works great! Thank you. > Awesome. That must be the fastest response ever ;-) Thanks a lot for testing. Olivier, I'm assigning this back to you; I believe there may still be a problem with window manager margins as shown in the second screenshot. I'll leave it to you to decide if this report can be closed. The panel side should be fixed now.
Margins are not xinerama aware, they've never been designed like that. It's just like struts (not partial struts, plain struts). Actually, margins are totally deprecated and should be dropped, it's non standard, xfce specific. It's kept just to avoid a complains from the few people who use it :)
> Actually, margins are totally deprecated and should be dropped, it's non > standard, xfce specific. Agreed. They are from before the strut support. > > It's kept just to avoid a complains from the few people who use it :) > He-he. Ok, I'll close the report then.
A small entry in the NEWS file would be great ;).