Actually I think it's a pretty funny one, not intending to be disrespectful against anyone.
Wonder what this is all about? Read more.
Maybe compare it with this mailing.
I got the multi-display setup I blogged about working after all.
Some issues though:
Beryl runs fine, but I kinda dislike the fact my cube is split over both monitor. Here's what'd really rock, IMHO: instead of having only 4 workspaces, allow me to have 8 workspaces. These are split, 1-4 go on one cube on my primary monitor, 5-8 are on another cube on the secondary display, so I got *2* cubes. It should still be possible to drag windows though: when workspace 2 and 7 are displayed, I should be able to drag a window from one to the other. There might be "overlap" issues here though, ie when the window is not completely on 2, nor completely on 7.
This might fix the different height issue too: workspaces 1-4 are 1280x768, workspaces 5-8 1280x1024. I don't know whether the necessary information can be queried (I guess RandR1.2 will allow this, but my bet is FGLRX won't have RandR1.2 support for over a year).
Last but not least I was thinking it could be pretty cool if composited window managers could handle output cloning. If you got 2 monitors attached to your computer, the WM/CM would see these as one large virtual monitor. It should be able to know about the different monitors though, the boundaries inside the virtual monitor,... If something is displayed then in the part of the virtual monitor (where windows are displayed) this should be copied to the other virtual part, so it's displayed on the secondary monitor too (sounds vague, hard to explain). While doing this, some resolution-bound enhancements could be done on the image to display too (you don't want to run a 4:3 17" TFT at 1280x768, everything looks *strange*), so all monitors can run at their native resolution. This is fairly easy to do using some matrix transformations on the input image, I guess OpenGL also allows this (windows are pixmaps on OpenGL vertices anyway IIRC).
Don't shoot me if some of these ideas are insane or technicly not feasible, this is just a braindump, I'm no X guru.
Anyway, up to writing my Gnome SoC proposal.
*edit* Beryl seems to have a setting to have 2 cubes indeed, but they just rotate their part of one workspace (enable the "3D world display" of windows, you'll see the borders), it's not 2 different workspaces, so when you rotate one cube, the other one rotates too.
Some pretty good news. Let's hope this will allow some more giant leaps on the FOSS Desktop "Bling" (including "useful" bling ;-)) front.
Going to write my SoC application(s) today, also fairly desktop-centered using not-yet-exploited features of our desktop infrastructure. Interesting times! I'll post more information later, mentors welcome ;-)
Old situation = laptop with 1280x768 display + Ati X1600 + fglrx + XGL + Beryl working fine.
New situation = old situation + 1280x1024 TFT connected to laptop VGA out
Desired situation = new situation + working Xinerama-like multihead setup (ie being able to move windows across both monitors, etc) including XGL/Beryl
What I got: after playing with fglrx settings, pairmode line etc, a normal Xorg server with TWM works, windows can be dragged across monitors,...
Whenever I restart GDM (and XGL) though, I can log in, then my standard Beryl-driven GNOME desktop is displayed on my laptop screen, and a second desktop (with its own panel etc) on the external screen. I'm unable though to move my mouse pointer to this screen, can not drag windows,... Basicly, the monitor and the desktop on it can't be used.
This is what I got in my XGL session:
$ fglrxinfo -display :1.0
Xlib: extension "XFree86-DRI" missing on display ":1.0".
Xlib: extension "XFree86-DRI" missing on display ":1.0".
display: :1.0 screen: 0
OpenGL vendor string: ATI Technologies Inc.
OpenGL renderer string: ATI Mobility Radeon X1600
OpenGL version string: 1.2 (2.0.6334 (8.34.8))
display: :1.0 screen: 1
OpenGL vendor string: ATI Technologies Inc.
OpenGL renderer string: ATI Mobility Radeon X1600
OpenGL version string: 1.2 (2.0.6334 (8.34.8))
$ xrandr
SZ: Pixels Physical Refresh
*0 1280 x 768 ( 342mm x 203mm ) *60 75 70 72 56 47
Current rotation - normal
Current reflection - none
Rotations possible - normal
Reflections possible - none
$ xdpyinfo | grep dimensions
dimensions: 1280x768 pixels (342x203 millimeters)
dimensions: 1280x1024 pixels (342x271 millimeters)
$ less /etc/X11/xorg.conf
Section "Device"
Identifier "ATI Graphics Adapter1"
Driver "fglrx"
VendorName "ATI Technologies Inc"
BoardName "ATI Radeon Mobility X1600"
Option "OpenGLOverlay" "on"
BusID "PCI:1:0:0"
Option "MonitorLayout" "LVDS, AUTO"
Option "Mode2" "1280x1024"
#Option "ForceMonitors" "LVDS, AUTO"
Option "DesktopSetup" "horizontal,reverse"
#Option "EnablePrivateBackZ" "yes"
Option "PairMode" "1280x768+1280x1024"
EndSection
It seems like the creation of Xwindows (when opening a menu, or a new application, etc) is very slow too :-( This might be just an impression though.
*update* Enabling Xinerama not by adding it in xorg.conf (doesn't work, enabling Xinerama disables DRI, so Xgl won't work), but by adding "+xinerama" to the Xgl start line in my custom gdm config file, seems to work... somewhat. I get my normal desktop on my laptop monitor, but only the standard grey-like X checkerboard on the external one. I can move my mouse pointer on it though, but get the default X cursor, not my normal one. I can't drag windows to it either, they seem not to get rendered. Maybe I got to recompile some packages to get Xinerama support...
Window creation isn't "slow" anymore too :-)
Strange though:
$ xdpyinfo | grep dimensions
dimensions: 1280x768 pixels (313x181 millimeters)
*update 2* Playing around some more with aticonfig doesn't solve the issue. It's pretty strange: whenever I'm in GDM, all looks fine. Once my GNOME session starts though, the system starts to clone the 1280x768 laptop monitor to the external monitor, which doesn't look very nice (wrong resolution), instead of providing me with a bigger screen, as when GDM is running. Pretty strange!
This is what xrandr says:
$ xrandr (omitted last lines) Choosing another mode doesn't solve the issue though :(
SZ: Pixels Physical Refresh
0 2560 x 1024 ( 684mm x 271mm ) 60
1 1280 x 1024 ( 684mm x 271mm ) 75 70 60
*2 1280 x 768 ( 684mm x 271mm ) *60
3 1024 x 768 ( 684mm x 271mm ) 75 72 70 60
Just read this interesting post. Had to change the read command somewhat to match my dmesg format (timestamps, you know).
Anyway, here's the result:
$ su -
# /etc/init.d/syslog-ng stop
# echo 1 > /proc/sys/vm/block_dump
# echo "Wait some time here, just use your desktop as usual"
# dmesg | gawk '/(READ|WRITE|dirtied)/ {activity[$3]++} END {for (x in activity) print activity[x],x}'| sort -nr | head -n 10 | gawk '{print $2 " " $1}'
pdflush(215): 160
evolution(7736): 149
pdflush(7670): 126
firefox-bin(7748): 26
gaim(7146): 12
jfsCommit(221): 5
gconfd-2(7114): 5
mono(7200): 4
mono(7199): 4
jfsIO(220): 4
# echo 0 > /proc/sys/vm/block_dump
# /etc/init.d/syslog-ng start
# exit
XML Feeds