On Dec 19, 08 12:23:20 +1100, Graeme Gill wrote:
Matthias Hopf wrote:
I have just pushed a change to radeonhd, that implements the mandatory
bits of RandR 1.3 output properties, which can thus be seen as a
reference implementation.
Sorry I guess I'm not following very well :- so this
Matthias Hopf wrote:
AFAIR we agreed on that this property name can just be changed without
breaking backward compatibility, because it was never agreed upon that
this was a standard so far.
I guess I can always add yet another EDID atom string check
to my display color profile management
On Dec 18, 08 18:34:26 +1100, Graeme Gill wrote:
Matthias Hopf wrote:
AFAIR we agreed on that this property name can just be changed without
breaking backward compatibility, because it was never agreed upon that
this was a standard so far.
I guess I can always add yet another EDID atom
On Thu, 2008-12-18 at 14:41 +0100, Matthias Hopf wrote:
I guess I can always add yet another EDID atom string check
to my display color profile management code, but is there a
reason to change it ?
Yeah, adopting a consistent standard property set will help applications
in the future as
Matthias Hopf wrote:
I have just pushed a change to radeonhd, that implements the mandatory
bits of RandR 1.3 output properties, which can thus be seen as a
reference implementation.
Sorry I guess I'm not following very well :- so this means that
the XRandR EDID_DATA atom now becomes what ?
On Nov 07, 08 19:50:18 +0100, Matthias Hopf wrote:
Attached is the new proposal. I hope I didn't forget any suggestion.
As there haven't been any additional comments, I have now committed this
proposal to randrproto.
There's a single change to the Xserver needed, the name of the raw EDID
data
On Oct 29, 08 17:08:25 -0700, [EMAIL PROTECTED] wrote:
- Is RANDR_BANDWIDTH helpful? Or should we have a dedicated property for
indicating dual link capability on DVI? What other meta information
(also on other connections) would be useful?
I think it would be better to just
On Oct 28, 08 14:37:30 -0700, Keith Packard wrote:
On Tue, 2008-10-28 at 19:51 +0100, Matthias Hopf wrote:
- Apparently there are only 8, 16, and 32bit integers available as
property types. Having ATOMs and FLOATs would add semantics, which
could help in some cases. But if this implies
On Fri, Nov 7, 2008 at 5:18 PM, Matthias Hopf [EMAIL PROTECTED] wrote:
On Oct 28, 08 14:37:30 -0700, Keith Packard wrote:
On Tue, 2008-10-28 at 19:51 +0100, Matthias Hopf wrote:
- Apparently there are only 8, 16, and 32bit integers available as
property types. Having ATOMs and FLOATs would
On Fri, Nov 7, 2008 at 5:19 PM, Matthias Hopf [EMAIL PROTECTED] wrote:
On Oct 28, 08 22:44:35 +0100, Maarten Maathuis wrote:
Is there any chance to get rid of strings in the protocol/server
altogether and stick to standardised names and properties (in the
form of enums) as much as possible?
On Nov 07, 08 18:48:18 +0100, Maarten Maathuis wrote:
On Fri, Nov 7, 2008 at 5:19 PM, Matthias Hopf [EMAIL PROTECTED] wrote:
On Oct 28, 08 22:44:35 +0100, Maarten Maathuis wrote:
Is there any chance to get rid of strings in the protocol/server
altogether and stick to standardised names and
On Nov 07, 08 18:46:20 +0100, Maarten Maathuis wrote:
Actually, single link/dual link, number of DisplayPort links, etc. could
be set in the same property.
I'd make that a generic transition frequency and an the total number
of links, unless there are connections that don't scale linearly in
On Fri, Nov 7, 2008 at 7:38 PM, Matthias Hopf [EMAIL PROTECTED] wrote:
On Nov 07, 08 18:48:18 +0100, Maarten Maathuis wrote:
On Fri, Nov 7, 2008 at 5:19 PM, Matthias Hopf [EMAIL PROTECTED] wrote:
On Oct 28, 08 22:44:35 +0100, Maarten Maathuis wrote:
Is there any chance to get rid of strings
Attached is the new proposal. I hope I didn't forget any suggestion.
Please comment.
Matthias
--
Matthias Hopf [EMAIL PROTECTED] ____ __
Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ [EMAIL PROTECTED]
Phone +49-911-74053-715 __) |_| __) |__ R D
On Nov 07, 08 19:44:07 +0100, Maarten Maathuis wrote:
Perhaps now would be the time to standardise on a beheaviour, my
personal opinion is that, the
user should see something that represents the connectors on the back
of their computer. Anything else should become a property of that
connector
On Fri, Nov 7, 2008 at 7:58 PM, Matthias Hopf [EMAIL PROTECTED] wrote:
On Nov 07, 08 19:44:07 +0100, Maarten Maathuis wrote:
Perhaps now would be the time to standardise on a beheaviour, my
personal opinion is that, the
user should see something that represents the connectors on the back
of
Matthias Hopf [EMAIL PROTECTED] writes:
ATOMs are obviously supported, but FLOATs seem harder as they aren't
described in the core protocol anywhere.
Thinking about that, adding floats was probably a bull idea. However,
having semantics about ATOMs might be helpful (e.g. for xrandr or any
This is a second try to establish a request for comments on the standard
properties of the upcoming RandR 1.3.
The first try died out pretty quickly, also due to /me being a lazy
bastard (read: other projects took away all of my time).
I finally updated the draft, as my original version wasn't
On Tue, Oct 28, 2008 at 10:37 PM, Keith Packard [EMAIL PROTECTED] wrote:
On Tue, 2008-10-28 at 19:51 +0100, Matthias Hopf wrote:
- Apparently there are only 8, 16, and 32bit integers available as
property types. Having ATOMs and FLOATs would add semantics, which
could help in some cases.
19 matches
Mail list logo
