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

[Keith Packard <keithp@keithp.com>]

[-- Attachment #1.1: Type: text/plain, Size: 3179 bytes --]

Pekka Paalanen <ppaalanen@gmail.com> 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...

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.

> 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.

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.

-- 
-keith

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel