GSoC Idea: better multi-head support

Aike J Sommer dev at aikesommer.name
Sat Mar 22 13:13:53 CET 2008


Am Freitag 21 März 2008 13:17:02 schrieb Aike J Sommer:
> > there is an application called krandrtray that provides a (KDE) GUI for
> > xrandr. it's not exactly perfect though, imho, and could use some
> > additional work. it's pretty much a straight translation between xrandr
> > and a UI. it could be made a lot more user friendly though, imho.
>
> I actually have that running here... It only makes use of xrandr 1.1 or is
> there a newer version somewhere??

Okay... Seems i was wrong with that... It does support XRandR 1.2, its just 
not working correctly here! I'll try to find the reason for that... :-)
So this would make an excellent starting point for the advanced 
configuration... And i really start to like the idea of a special plasmoid 
that would:
- Visualize the current configuration, showing a laptop and an external 
monitor side-by-side when its plugged in for example
- Allow to rearrange them on the fly, dragging one of them around
- Allow to change resolution and refresh rate from a context-menu
- Switch "purpose" from a context-menu, thus assigning a new containment or 
start a certain application on that screen

> > what sort of feedback in the pager?
>
> It should show all monitors with respect to their relative sizes and
> positions...
> The highlighted virtual desktop might be the just the part representing the
> monitor where the mouse is currently on... These are just some quick ideas,
> hope it kinda makes sense! :-)
> I would love to have totally independent virtual-desktops per screen too,
> but i guess that would require aditional support from kwin! Actually now
> that i think about it, that might be relatively easy to do without support
> from kwin... I'll try that 2nite!! :-)

So... I finally managed to get the compile of trunk done... And started to 
play around on that matter!
It was actually kinda easy to make it "seem" like the 2 monitors have 
indpendent virtual desktops... It basically works by having n*m virtual 
desktops and remapping the windows depending on the monitor they r currently 
on and the selected desktop!
The plus is: it can be done by a simple app listening to windowing-events, 
having a pager that "understands" this would be a plus of course!! ;-)
The downside: its a hack ;-) and there is slight flicker when the window is 
remapped!

On the state of monitor-hotplug-support in current trunk:
It doesnt seem to be really working well... I had the following things 
happening: (this is with compositing turned off)
- desktop background does not extend to both screens, i had 2 different 
results:
  - it would stay at 1400x1050 but move to the smaller external screen, 
resulting in a 376 pixel wide strip of the wallpaper on the left of the 
internal screen
  - it would resize to 1024x768 and move to the external screen, this would 
then leave a 376 pixel wide strip of grey and white squares on the internal 
screen
- the rest of the background would be grey in both cases and doesnt respond to 
clicks with the rmb
- with the background staying at 1400x1050 the panel was not visible on the 
external screen, but "overlapped" onto the internal screen
- Once i had the contents of the external display replicated at 376 pixels 
into the internal screen, with the internal one still "left-of" to the 
external one, this might have been a problem with the driver or myself, 
though!! ;-)

BTW: None of those problems ocurred when the external display was set to be 
left-of the internal one before KDE was started

Overall i think that i start to get a way better understanding of what would 
be needed to make hotplugging of monitors "smooth" in KDE... I'll write up a 
new propsal later 2day!!

:-)


More information about the Panel-devel mailing list