Re: xrandr - Multiple monitors, one rotated, mouse can disappear into non-desktop space

[Felix Miata]

Ryan Felder composed on 2017-05-02 12:10 (UTC-0500):
...
> I cannot seem to find any xrandr setting to address this. I am running
> Ubuntu 16.04, Elementary/Pantheon desktop environment. My xrandr output is
> below. Is there anything I can do to fix this?
> 
> Screen 0: minimum 8 x 8, current 3125 x 1920, maximum 32767 x 32767
> DP1 disconnected (normal left inverted right x axis y axis)
> DP2 disconnected (normal left inverted right x axis y axis)
> HDMI1 connected primary 1200x1920+0+0 left (normal left inverted right x
...
> HDMI2 connected 1920x1200+1205+538 (normal left inverted right x axis y
> axis) 520mm x 320mm
> VGA1 disconnected (normal left inverted right x axis y axis)
> VIRTUAL1 disconnected (normal left inverted right x axis y axis)

How has rotation of HDMI1 been set up? Maybe the problem is caused by the 5mm
gap between the two displays (or the tool that configured the rotation), and
eliminating the gap or changing the tool would solve the problem?
-- 
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

xrandr - Multiple monitors, one rotated, mouse can disappear into non-desktop space

[Ryan Felder]

I can't seem to find any mention of this elsewhere. I have two monitors on
a machine, the primary is portrait, the secondary is landscape. I can
'lose' my mouse in the empty space above my landscape monitor.

If I have two monitors of different sizes, but no rotation, the mouse stops
at the screen border where I would expect, preventing me from losing my
mouse, but this functionality does not appear to be preserved when rotation
is the cause of the different sized monitors.

I cannot seem to find any xrandr setting to address this. I am running
Ubuntu 16.04, Elementary/Pantheon desktop environment. My xrandr output is
below. Is there anything I can do to fix this?

Screen 0: minimum 8 x 8, current 3125 x 1920, maximum 32767 x 32767
DP1 disconnected (normal left inverted right x axis y axis)
DP2 disconnected (normal left inverted right x axis y axis)
HDMI1 connected primary 1200x1920+0+0 left (normal left inverted right x
axis y axis) 520mm x 320mm
   1920x1200 59.95*+
   1920x1080 60.00
   1600x1200 60.00
   1680x1050 59.88
   1280x1024 60.02
   1280x960  60.00
   1024x768  60.00
   800x600   60.32
   640x480   59.94
   720x400   70.08
HDMI2 connected 1920x1200+1205+538 (normal left inverted right x axis y
axis) 520mm x 320mm
   1920x1200 59.95*+
   1920x1080 60.00
   1600x1200 60.00
   1680x1050 59.88
   1280x1024 60.02
   1280x960  60.00
   1024x768  60.00
   800x600   60.32
   640x480   59.94
   720x400   70.08
VGA1 disconnected (normal left inverted right x axis y axis)
VIRTUAL1 disconnected (normal left inverted right x axis y axis)
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: Proposal for RandR version 1.6, Leases and EDID-based output grabs

[Keith Packard]

Pekka Paalanen  writes:

> I was under the impression that if you have a VR application running on
> the HMD, it necessarily also implies that you have a VR compositor
> running, which means that there is always some process providing a valid
> image to the HMD. (At least in end-user setups.)

Yes, I think the point I was trying to make was that X should never
attempt to talk to the HMD and provide an image.

> I assumed that means there are no VR apps nor a VR compositor that
> could handle the HMD. In that case I think the HMD should be always
> off.

Agreed.

> I presume that if "desktop" is set to "true", it implies that the HMD
> is capable of showing a simple 2D canvas in stereo without any special
> rendering and with the default video mode. That is, creating a sort of
> a virtual 2D monitor. That would be nice.

I was thinking that 'desktop' would be true for non-HMD displays that
didn't need the VR compositor. If you've got a VR compositor and want to
paint the desktop inside the VR environment, then I think you'd want to
create a synthetic monitor and hand images from that to the VR
compositor each frame.

> FWIW, it all sounds good to me!
>
> I don't really have an opinion on XML vs. JSON, I'm just happy it's not
> another ad hoc format.

Yeah, I think we're done with ad-hoc formats. I've done both XML and
JSON, and JSON is way easier to hand write, but we already use XML in a
bunch of places, so the necessary libaries are already linked into the
server...

-- 
-keith


signature.asc
Description: PGP signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: Xvfb concerns and dummy driver issues

[Adam Jackson]

On Fri, 2017-04-28 at 14:24 -0400, David Jackson wrote:
> Is the plan to keep Xvfb as-is (KDrive?)

As-is, yes. Strictly speaking, Xvfb is not a kdrive server, in the same
sense that Xorg is not a kdrive server. There was a very similar kdrive
server named Xfake, and that was indeed deleted.

> Any ideas about why the dummy driver was not working (killing the
> headless dummy X server brings down any X server running on hardware,
> like the dummy X server somehow gets entangled with other X servers
> on the system),

By default, the Xorg server will remember which virtual terminal it was
launched from (if any), and will attempt to switch back to it when it
exits (or regenerates). So if you start both the dummy and hardware
server from the console, terminating either one will switch back to the
console, which may look like you're "bringing down" the other one.

You can suppress this by launching the dummy server with '-novtswitch'
on the command line.

> and problems playing video?

I'm not sure this is specific enough to guess at.

- ajax
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: Proposal for RandR version 1.6, Leases and EDID-based output grabs

[Pekka Paalanen]

On Fri, 28 Apr 2017 15:03:17 -0700
Keith Packard  wrote:

> Pekka Paalanen  writes:
> 
> > IMHO, if nothing is providing a picture intended for the HMD, the HMD
> > should be off. There is no use in showing an arbitrary image that does
> > not look right, is there?  
> 
> Well, if the HMD is being worn and the application crashes, then
> what you want is something that keeps responding to your motion so you
> can get the HMD off without falling or running into stuff...

Hi,

I was under the impression that if you have a VR application running on
the HMD, it necessarily also implies that you have a VR compositor
running, which means that there is always some process providing a valid
image to the HMD. (At least in end-user setups.)

Here the assumption is that the application may crash or stall, but the
VR compositor never will. Obviously that's not exactly true, but if we
design for also the VR compositor crashing or stalling, then we have a
requirement for a tertiary process that is essentially just like the
VR compositor. And so the turtles pile up... which is also why I don't
think a backup plan for the VR compositor is necessary.

Or did you have an idea of something extremely simple that could still
provide a reasonable image for the HMD even when the compositors have
crashed and the GPU is frozen?

However, your original question was:

>  * What should we do with an HMD which is in the database but for which
>no application is installed on the host?  

I assumed that means there are no VR apps nor a VR compositor that
could handle the HMD. In that case I think the HMD should be always off.

> But, yeah, in general, if you don't have an HMD application running, the
> HMD can't usefully show anything from a bare window system. The trick is
> to make sure existing desktop applications don't try to use it by mistake.

Sure.

> > even if the database was just a bunch of files, you still need code to
> > access it, and probably something to ensure the entries are
> > well-formed, so that everyone will agree on how to parse them. One
> > should probably decide whether the database will only answer the
> > question "is it a HMD?" or can it provide other information as well.  
> 
> Yup, we need a spec for the files that is reasonably sane, and also
> extensible so that if we want to add new data, we can. I discussed this
> with Eric Anholt at breakfast this morning and we came up with a couple
> of ideas:
> 
>  1) A directory full of files, each file can contain one or more monitor
> entries
> 
>  2) Monitors should be identified (at a minimum) using the EDID
> Manufacturer ID and Manufacturer product code. I can imagine
> also allowing the use of a serial number and/or date code if we end
> up using this for more stuff later.
> 
>  3) Window system independent. We obviously need this for X, but
> other window systems should share the same data.
> 
>  4) Use an existing format. Both of us would rather use JSON, but
> there's already XML in the DRM world, so that might make
> sense. These are functionally equivalent, but XML syntax is rough on
> the eyes.
> 
>  5) Allow multiple definitions in each file, but allow for multiple
> files too.
> 
> Here's a JSON-formatted example:
> 
> {
> "monitors": [
> {
> "Manufacturer" : "LGD",
> "Product" : 437,
> "desktop" : true
> }
> ]
> "copyright" : "Copyright © 2017, Keith Packard",
> "license" : "GPLv3"
> }
> 
> One can imagine the same done in XML, but I'm too lazy to type that
> here. In any case, as you can see above, I've added a "desktop" field;
> if false, the monitor would be hidden to 'normal' desktop applications
> and only made visible to others.

I presume that if "desktop" is set to "true", it implies that the HMD
is capable of showing a simple 2D canvas in stereo without any special
rendering and with the default video mode. That is, creating a sort of
a virtual 2D monitor. That would be nice.

> Questions:
> 
>  Q) Where should the directory live.
> 
>  A) /usr/share/monitors for distribution-provided files, /etc/monitors
> for application-provided files.
> 
>  Q) How about RandR protocol.
> 
>  A) I'm thinking of just creating a new randr request like
> RRGetOutputInfo but which will return even "hidden" outputs with
> non-spoofed 'connection' value.
> 
>  Q) What file names should the entries use.
> 
>  A) How about just the manufacturer and product of the first entry?
> 
>  Q) Ranges of product ids?
> 
>  A) Yeah, we might want this to avoid a lot of duplicate entries.
> 

FWIW, it all sounds good to me!

I don't really have an opinion on XML vs. JSON, I'm just happy it's not
another ad hoc format.


Thanks,
pq


pgpcfqt7NIyh4.pgp
Description: OpenPGP digital signature
___