I am testing a tri-head setup on 13.10 with my Lenovo T430 with the new xserver-xorg-video-intel. I have my laptop screen, DP1 right of it, and DP2 right of it -- rotated. This works with puetzk's screenclone, I also need to specify rotation for the second screen of DISPLAY :8 and use a "rotated" mode (1200x1920) for the second virtual screen. (See http://askubuntu.com/a/303897/30266 for more information.)
I wonder if `intel-virtual-output` could be enhanced to support rotated displays.
If possible, I would like to use `intel-virtual-output` instead of `screenclone` because it does all necessary setup. I'll be glad to test a patch before it's applied upstream.
Note that, with the default xserver-xorg-video-intel in Ubuntu 13.10, the virtual screen cannot be rotated using `xrandr --rotate ...`. Using a "rotated" mode (1200x1920) works.
The code does copy across the rotation from the VIRTUAL to the remote display. Hopefully it is just a trivial bug... What it can't acutally do is back-propagate the limits from the remote display, but that doesn't sound like the issue here.
xrandr -d :0 --verbose
xrandr -d :8 --verbose
would be very useful
I cannot set rotation for the VIRTUAL display:
xrandr ... --output VIRTUAL1 --rotate left
throws an error, I can post exact error message tomorrow.
This is with most recent xserver-xorg-video-intel from the Ubuntu repos (no edgers/x-swat).
Created attachment 89579 [details]
xrandr -d :0 --verbose (Ubuntu 13.04 system with patched Intel driver)
Created attachment 89580 [details]
xrandr -d :8 --verbose (Ubuntu 13.04 system with patched Intel driver)
This is what I see when attempting to rotate a virtual display:
$ xrandr --output VIRTUAL5 --rotate left
xrandr: output VIRTUAL5 cannot use rotation "left" reflection "none"
Created attachment 89581 [details]
xrandr -d :0 --verbose (Ubuntu 13.10 system with stock Intel driver after intel-virtual-output -b)
Created attachment 89582 [details]
xrandr -d :8 --verbose (Ubuntu 13.10 system with stock Intel driver after intel-virtual-output -b)
Author: Chris Wilson <firstname.lastname@example.org>
Date: Wed Nov 20 18:50:40 2013 +0000
sna: Set supported rotations on virtual outputs
As the virtual outputs are created later, they do not get automatically
populated with RR properties and we must do that instantiation
Reported-by: Kirill Müller <email@example.com>
Signed-off-by: Chris Wilson <firstname.lastname@example.org>
Updated to tip of Git.
Rotation now works. When I rotate the third screen (VIRTUAL5), I also have to rotate the corresponding Bumblebee screen (DP-2). When I do this, I see that the desktop area is adapted, but the lower part of the third screen (y >= 1200) is not updated and remains black.
- Any chance to auto-rotate DP-2?
- Hope it's easy to compute the correct update area even in the case of rotation.
Thanks a lot.
When I did it locally, the rotation was propagated through to the remote display as expected. :|
Is not on my system, I have checked again. The ivo.txt I have attached to the other ticket is without rotation -- does it make sense to repeat the exercise with rotation, or do you have to add more debugging code up front?
Created attachment 89746 [details]
As requested, result of intel-virtual-output -b -f | tee ivo2.txt
I did the following:
- Turned off and on the third (=second virtual) display
- Set up rotation for the third display
- Issued `xrandr -d :8 --output DP-2 --rotate left` (because the rotation is still not propagated)
- Moved the cursor to the third display and back (still not shown on the third display, see linked ticket)
Everything seems to work, except for updating a part of the rotated screen (I guess the one below 1200 pixels). Could you check if the routine that copies screen contents respects rotation? To me it looks like it tries to copy 1920x1200 when it should copy 1200x1920.
Created attachment 89747 [details]
As requested, result of inAs requested, result of intel-virtual-output -b -f | tee ivo2.txt tel-virtual-output -b -f | tee ivo3.txt
Like the previous attachment, but this time really against Git tip. Cursor is shown on third monitor, copying issue persists.
It is not reporting that VIRTUAL2 is rotated. Can you please attach the current xrandr --verbose? (Make sure that the ddx is also updated, so please also attach the Xorg.0.log.)
Created attachment 89757 [details]
Another result of intel-virtual-output -b -f | tee ivo4.txt
Another run. Here are the commands used to set up rotation:
$ xrandr --output LVDS1 --output VIRTUAL4 --right-of LVDS1 --output VIRTUAL5 --right-of VIRTUAL4 --rotate left
$ xrandr -d :8 --output DP-1 --output DP-2 --right-of DP-1 --rotate left
Everything still works, except for updating pixels 1200-1920 on the vertical.
Xorg.0.log follows. What's a DDX?
Do you still need xrandr --verbose?
Created attachment 89758 [details]
(In reply to comment #15)
> Xorg.0.log follows. What's a DDX?
ddx = display dependent X, i.e. the hardware driver portion of X - xf86-video-intel
> Do you still need xrandr --verbose?
Please. I want to see what it reports the available rotation modes as, and what the current is.
Created attachment 89760 [details]
xrandr -d :0 --verbose (Ubuntu 13.10 system with stock Intel driver after intel-virtual-output -b, second try)
Created attachment 89761 [details]
xrandr -d :8 --verbose (Ubuntu 13.10 system with stock Intel driver after intel-virtual-output -b, second try)
I usually say `make && sudo make install` and then reboot. Hope that gets the DDX set up.
Hmm, xrandr is working as I would expect. Can I ask you do a git pull and repeat your testing (but exclude the final xrandr -d :8 fixup) and attach the fresh Xorg.0.log, ivo.txt, xrandr --verbose -d :0 and xrandr --verbose -d :8
Created attachment 89763 [details]
Created attachment 89764 [details]
Created attachment 89765 [details]
Created attachment 89766 [details]
in this order:
- xrandr :0, :8
After pulling, make-ing, installing and restarting. No rotation applied to DP-2.
Thanks for looking into it, I'm in a hurry now.
Ah, it fails to apply the rotated mode. Probably because the fb is too small for the rotated mode. Update for you to test.
Created attachment 89813 [details]
Created attachment 89814 [details]
Created attachment 89815 [details]
Created attachment 89816 [details]
Same order as before.
Now the third display is rotated properly, no need to say `xrandr -d :8 --rotate left`. However, on the third display the part below 1200 pixels to the vertical is still black. This even happens if the second display is below the first, and the third is right of the first (so that display areas actually overlap).
The `ivo6.txt` shows how I move the mouse into the black area, and also how I drag a window to the black area (and back). Something on my system (perhaps the `DISPLAY` applet) remembers how I want the screens to be set up, so I didn't have to do anything w.r.t. that for this run.
Created attachment 89818 [details]
...entire desktop. It seems to have proper dimensions, it's just that the "real" display (DP-2) doesn't get updated in this configuration (the lower area of the right display is blank).
Created attachment 89819 [details]
Screen-shot with proper MIME type
Author: Chris Wilson <email@example.com>
Date: Tue Nov 26 08:52:39 2013 +0000
intel-virtual-output: Correct clip region of rotated outputs in source framebuffer
Thanks a lot for your help and for the ultrafast response times. When can I expect this version to appear in the default Ubuntu repos? Or do I have to use Xorg-edgers or Swat or ...?
In theory, it should pop up in xorg-edgers within 48 hours - but I think it is being a little slow lately. Before it gets updated in Ubuntu proper, I need to make a release - I'm trying to get some new bits together for a new snapshot and a proper release, but since Ubuntu is already lagging behind a couple of snapshots, we may not see an update until they focus on the display server for 14.04 (i.e. it may be a month or two yet).
I kind of expected that. Would you recommend running everything from stock Ubuntu and only install the Intel driver from edgers in a production system?
Yes. The driver should function as a drop in replacement on any system (the only caveat is that it has to be compiled for that system to get the right ABI) for the past 7 years or so.