X server 1.6 release schedule
I volunteered to manage an X server 1.6 release, tentatively scheduled for the end of the year (yes, this year, 2008). This release will include DRI2 and RandR 1.3 support. I'd like to know how much of the new Xinput stuff will be ready in time. Here's a proposed schedule of events: Cut a release branch, do a -RC1 release:11/24 Track remaining work on scheduled features, cherry-picking commits from master. Cut -RC212/8 Stop accepting new code, focus on bug fixing. Cut -RC312/22 Update documentation, mark known bugs, build packages and ship final bits. 1/5 After -RC1, all commits to the branch must go through the 1.6 proposed commits page: http://wiki.x.org/wiki/Server16Branch If you've got merges you'd like to have included, instead of just a patch or two, please post the repository and branch name. I'll pull stuff across and push to the branch. -- [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X server 1.6 release schedule
On 13:13 Fri 14 Nov , Keith Packard wrote: > Here's a proposed schedule of events: > > Cut a release branch, do a -RC1 release: 11/24 > > Track remaining work on scheduled features, > cherry-picking commits from master. Cut -RC2 12/8 > > Stop accepting new code, focus on bug fixing. > Cut -RC3 12/22 > > Update documentation, mark known bugs, build > packages and ship final bits. 1/5 Sounds fine on the Gentoo front. I would like one minor change, though. Let's only give the RC tag to things that are truly candidates for a final release and are not adding new features. Those would be betas instead, so it would be like this: 1.6_beta1: 11/24 1.6_beta2: 12/08 1.6_rc1: 12/22 1.6_rc2: 12/29 1.6: 01/05 -- Thanks, Donnie Donnie Berkholz Developer, Gentoo Linux Blog: http://dberkholz.wordpress.com pgpkihlDgdxRV.pgp Description: PGP signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X server 1.6 release schedule
Le 14/11/2008 22:13, Keith Packard a écrit : > I volunteered to manage an X server 1.6 release, tentatively scheduled > for the end of the year (yes, this year, 2008). This release will > include DRI2 and RandR 1.3 support. I'd like to know how much of the new > Xinput stuff will be ready in time. Any chance to get the glyph cache in 1.6 or is it still considered too experimental? Thanks Rémi ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X server 1.6 release schedule
> I volunteered to manage an X server 1.6 release, tentatively scheduled > for the end of the year (yes, this year, 2008). This release will > include DRI2 and RandR 1.3 support. I'd like to know how much of the new > Xinput stuff will be ready in time. Hi Keith, First, thanks for doing it. I understand that people should rely on tarballs available at http://xorg.freedesktop.org/releases/individual, but given that "packages" like X Server, libdrm and mesa have "stable branches", I would like to see those more used, and people being able to clone those repositories and building from source, from the stable branches. Several distros (Mandriva is one) did not yet update from 1.4 to 1.5. Since I want to believe that 1.5 to 1.6 will not have major abi changes, this could be a good oportunity for distros to get back in sync with Xorg. I guess it will be required to skip https://bugs.freedesktop.org/show_bug.cgi?id=14730 again. I had that patch working for X Server 1.4 one year ago, and for git master before 1.5 was "branched". But did not test it much recently. Anyway, it probably should stay this way, as the patch would be more useful when/if Xorg started using a sdk, with a compromise on backwards compatibility. But at the rate new features are being added, this is unlikely soon :-) Also by only exporting symbols that really should be visible, you get a compromise. Due to the large amount of changes, this is also something that will cause potential "personal" conflicts, if you add patches to "someone else's" package. So, instead of changing configure.ac's and Makefile.am's, maybe make it modify XORG_CFLAGS; if the X Server can compile and become functional with -fvisibility, there is no reason drivers won't; only libraries of course needs special handling, and in most cases, just mark as weak duplicated symbols, and make sure the X Server is exporting it's version of the symbol. > Here's a proposed schedule of events: > > Cut a release branch, do a -RC1 release: 11/24 > > Track remaining work on scheduled features, > cherry-picking commits from master. Cut -RC2 12/8 > > Stop accepting new code, focus on bug fixing. > Cut -RC3 12/22 > > Update documentation, mark known bugs, build > packages and ship final bits. 1/5 > > After -RC1, all commits to the branch must go through the 1.6 proposed > commits page: > > http://wiki.x.org/wiki/Server16Branch > > If you've got merges you'd like to have included, instead of just a > patch or two, please post the repository and branch name. I'll pull > stuff across and push to the branch. > > -- > [EMAIL PROTECTED] > ___ Paulo ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X server 1.6 release schedule
On Sat, 2008-11-15 at 09:34 +0100, Rémi Cardona wrote: > Le 14/11/2008 22:13, Keith Packard a écrit : > > I volunteered to manage an X server 1.6 release, tentatively scheduled > > for the end of the year (yes, this year, 2008). This release will > > include DRI2 and RandR 1.3 support. I'd like to know how much of the new > > Xinput stuff will be ready in time. > > Any chance to get the glyph cache in 1.6 or is it still considered too > experimental? The glyph cache code has been on master for months. Anything on master is going into 1.6, unless we find regressions. -- [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X server 1.6 release schedule
On Nov 14, 2008, at 14:03, Donnie Berkholz wrote: On 13:13 Fri 14 Nov , Keith Packard wrote: Here's a proposed schedule of events: Cut a release branch, do a -RC1 release:11/24 Track remaining work on scheduled features, cherry-picking commits from master. Cut -RC212/8 Stop accepting new code, focus on bug fixing. Cut -RC312/22 Update documentation, mark known bugs, build packages and ship final bits. 1/5 Sounds fine on the Gentoo front. I would like one minor change, though. Let's only give the RC tag to things that are truly candidates for a final release and are not adding new features. Those would be betas instead, so it would be like this: 1.6_beta1: 11/24 1.6_beta2: 12/08 1.6_rc1: 12/22 1.6_rc2: 12/29 1.6: 01/05 Yeah... I second that... Also, is there any objection to my pushing xquartz-specific patches directly into server-1.6-branch rather than putting them into the cherry-pick-nomination wiki list? I've gotten the impression before that "if it's #ifdef XQUARTS or in hw/xquartz, we don't care" ... so I'm assuming that's ok... and if I need anything more than that, I'll nominate it in the wiki list... smime.p7s Description: S/MIME cryptographic signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X server 1.6 release schedule
Le 16/11/2008 02:43, Keith Packard a écrit : > Anything on master is going into 1.6, unless we find regressions. Reading your mail, I was under the impression you'd be starting a 1.6 branch on top of 1.5 and then cherry-picking DRI2 and RR1.3 patches on top of it. I'm glad to hear you'll be using master directly. Thanks ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X server 1.6 release schedule
On Fri, 2008-11-14 at 14:03 -0800, Donnie Berkholz wrote: > 1.6_beta1: 11/24 > 1.6_beta2: 12/08 > 1.6_rc1: 12/22 > 1.6_rc2: 12/29 > 1.6: 01/05 Sounds good to me. -- [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X server 1.6 release schedule
On Fri, Nov 14, 2008 at 01:13:16PM -0800, Keith Packard wrote: > I volunteered to manage an X server 1.6 release, tentatively scheduled > for the end of the year (yes, this year, 2008). This release will > include DRI2 and RandR 1.3 support. I'd like to know how much of the new > Xinput stuff will be ready in time. Input device properties - yes Pointer acceleration- yes X Input 2/MPX - no After the branching, I'll provide patches to disable MPX. We can still use the whole subsystem, but w/o the ability to create new MDs. Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X server 1.6 release schedule
On Nov 14, 08 13:13:16 -0800, Keith Packard wrote: > I volunteered to manage an X server 1.6 release, tentatively scheduled > for the end of the year (yes, this year, 2008). This release will > include DRI2 and RandR 1.3 support. I'd like to know how much of the new > Xinput stuff will be ready in time. Keith, AFAICS the standard properties do not inflict any changes on server code except for the naming of the EDID data property, so I assume that's fine here. I'm unsure whether it would be wise to include panning support in 1.3, even given that I manage to put it together until 11/24. I guess it should settle in master first. In that case, do we have any protocol changes in 1.3? Do we need a version bump then? Matthias -- Matthias Hopf <[EMAIL PROTECTED]> ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ [EMAIL PROTECTED] Phone +49-911-74053-715 __) |_| __) |__ R & D www.mshopf.de ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X server 1.6 release schedule
On Mon, 2008-11-17 at 13:08 +0100, Matthias Hopf wrote: > Keith, AFAICS the standard properties do not inflict any changes on > server code except for the naming of the EDID data property, so I assume > that's fine here. Yup. > I'm unsure whether it would be wise to include panning support in 1.3, > even given that I manage to put it together until 11/24. I guess it > should settle in master first. I'd like to get panning into 1.6; it's not a huge driver change as we already support all of the needed functionality. > In that case, do we have any protocol changes in 1.3? Do we need a > version bump then? The projective transforms require a protocol bump, hence wanting to get all of the RandR 1.3 protocol changes included. -- [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X server 1.6 release schedule
On Nov 17, 08 09:21:55 -0800, Keith Packard wrote: > > I'm unsure whether it would be wise to include panning support in 1.3, > > even given that I manage to put it together until 11/24. I guess it > > should settle in master first. > I'd like to get panning into 1.6; it's not a huge driver change as we > already support all of the needed functionality. Ok, then I'll try to fix up something until the end of the week. > > In that case, do we have any protocol changes in 1.3? Do we need a > > version bump then? > The projective transforms require a protocol bump, hence wanting to get > all of the RandR 1.3 protocol changes included. ... that happens if you read and reply to your emails top-down ;-) Matthias -- Matthias Hopf <[EMAIL PROTECTED]> ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ [EMAIL PROTECTED] Phone +49-911-74053-715 __) |_| __) |__ R & D www.mshopf.de ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X server 1.6 release schedule
On Sat, 2008-11-15 at 15:57 -0200, Paulo César Pereira de Andrade wrote: > > I volunteered to manage an X server 1.6 release, tentatively scheduled > > for the end of the year (yes, this year, 2008). This release will > > include DRI2 and RandR 1.3 support. I'd like to know how much of the new > > Xinput stuff will be ready in time. > > I guess it will be required to skip > https://bugs.freedesktop.org/show_bug.cgi?id=14730 again. > I had that patch working for X Server 1.4 one year ago, and for > git master before 1.5 was "branched". But did not test it much > recently. Anyway, it probably should stay this way, as the patch would > be more useful when/if Xorg started using a sdk, with a compromise on > backwards compatibility. But at the rate new features are being added, > this is unlikely soon :-) Also by only exporting symbols that really > should be visible, you get a compromise. Actually, I've been meaning to get this merged for a while now. I'll be happy to take a look at it again. - ajax signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X server 1.6 release schedule
On Fri, 2008-11-14 at 13:13 -0800, Keith Packard wrote: > I volunteered to manage an X server 1.6 release, tentatively scheduled > for the end of the year (yes, this year, 2008). This release will > include DRI2 and RandR 1.3 support. I'd like to know how much of the new > Xinput stuff will be ready in time. Can we define what RANDR 1.3 means? I think we're largely in agreement but I'd like it written down. > Here's a proposed schedule of events: > > Cut a release branch, do a -RC1 release: 11/24 > > Track remaining work on scheduled features, > cherry-picking commits from master. Cut -RC2 12/8 > > Stop accepting new code, focus on bug fixing. > Cut -RC3 12/22 > > Update documentation, mark known bugs, build > packages and ship final bits. 1/5 Sounds like a busy holiday, but since it's not _my_ busy holiday, I don't mind at all. There is still one major bugfix that was only ever applied to 1.5 branch and not master: commit 7822a3d05f935cca3bfa47d15d961596652ecfca Author: Adam Jackson <[EMAIL PROTECTED]> Date: Tue Jun 17 16:10:51 2008 -0400 XAA: Disable offscreen pixmaps by default. Say Option "XaaOffscreenPixmaps" to turn them back on. Apropos of bugs #13795 and #15098. Not yet applied to master as this wants a proper solution someday, but then, those bugs aren't closed yet either. Other than that I think the fixes in 1.5.x are a strict subset of what's in master. I'll probably wind down the 1.5 series with one last release when 1.6.0 goes out. - ajax signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X server 1.6 release schedule
Adam Jackson wrote: > There is still one major bugfix that was only ever applied to 1.5 branch > and not master: > > commit 7822a3d05f935cca3bfa47d15d961596652ecfca > Author: Adam Jackson <[EMAIL PROTECTED]> > Date: Tue Jun 17 16:10:51 2008 -0400 > > XAA: Disable offscreen pixmaps by default. > > Say Option "XaaOffscreenPixmaps" to turn them back on. > > Apropos of bugs #13795 and #15098. Not yet applied to master as this > wants > a proper solution someday, but then, those bugs aren't closed yet either. > > Other than that I think the fixes in 1.5.x are a strict subset of what's > in master. I'll probably wind down the 1.5 series with one last release > when 1.6.0 goes out. Probably not related to those bugs, but XAA doesn't have a flag to call the "sync function" for screen to screen copy after every "sub blit" on hardware that has only 2 directions copy. There was a certain crash with the siliconmotion driver (smi 502) a few seconds after opening youtube, due to the animations on the web page overflowing the engine and locking the entire system. Disabling xaa offscreen pixmaps caused it to do enough computations to not overflow the engine... After changing the xaa code to ensuring the engine is idle before every "subsequent screen to screen copy", the problem was corrected. > - ajax Paulo ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X server 1.6 release schedule
On Tue, 2008-11-18 at 14:42 -0500, Adam Jackson wrote: > On Fri, 2008-11-14 at 13:13 -0800, Keith Packard wrote: > > I volunteered to manage an X server 1.6 release, tentatively scheduled > > for the end of the year (yes, this year, 2008). This release will > > include DRI2 and RandR 1.3 support. I'd like to know how much of the new > > Xinput stuff will be ready in time. > > Can we define what RANDR 1.3 means? I think we're largely in agreement > but I'd like it written down. I think RandR 1.3 includes: 1. Projective transforms 2. Standard properties 3. Per-CRTC DPMS controls 4. Panning Are there other pieces that should land in time? > There is still one major bugfix that was only ever applied to 1.5 branch > and not master: Let's get stuff merged across then. -- [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X server 1.6 release schedule
On Tue, 2008-11-18 at 14:36 -0800, Keith Packard wrote: > On Tue, 2008-11-18 at 14:42 -0500, Adam Jackson wrote: > > On Fri, 2008-11-14 at 13:13 -0800, Keith Packard wrote: > > > I volunteered to manage an X server 1.6 release, tentatively scheduled > > > for the end of the year (yes, this year, 2008). This release will > > > include DRI2 and RandR 1.3 support. I'd like to know how much of the new > > > Xinput stuff will be ready in time. > > > > Can we define what RANDR 1.3 means? I think we're largely in agreement > > but I'd like it written down. > > I think RandR 1.3 includes: > > 1. Projective transforms > 2. Standard properties > 3. Per-CRTC DPMS controls > 4. Panning Overscan correction? I don't think this counts as a subset of projective transforms, but I could be wrong. - ajax signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X server 1.6 release schedule
On Tue, 2008-11-18 at 18:23 -0500, Adam Jackson wrote: > Overscan correction? I don't think this counts as a subset of > projective transforms, but I could be wrong. No, not a part of projective transforms as it doesn't change the pixel->pixel mapping. It sounds useful; get some code together along with a spec update and we can ship it too. -- [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X server 1.6 release schedule
> On Sat, 2008-11-15 at 15:57 -0200, Paulo César Pereira de Andrade wrote:
>> > I volunteered to manage an X server 1.6 release, tentatively scheduled
>> > for the end of the year (yes, this year, 2008). This release will
>> > include DRI2 and RandR 1.3 support. I'd like to know how much of the
>> new
>> > Xinput stuff will be ready in time.
>>
>> I guess it will be required to skip
>> https://bugs.freedesktop.org/show_bug.cgi?id=14730 again.
>> I had that patch working for X Server 1.4 one year ago, and for
>> git master before 1.5 was "branched". But did not test it much
>> recently. Anyway, it probably should stay this way, as the patch would
>> be more useful when/if Xorg started using a sdk, with a compromise on
>> backwards compatibility. But at the rate new features are being added,
>> this is unlikely soon :-) Also by only exporting symbols that really
>> should be visible, you get a compromise.
>
> Actually, I've been meaning to get this merged for a while now. I'll be
> happy to take a look at it again.
I think the patches should still apply (besides some patches for
mfb and glx/*.c). But I can review it again.
Actually, I built a framework to work on this. I added the xedit
ctags interface just for this :-), and wrote a perl script that will
use objdump to list all external symbols provided/required by modules
and X Server, and print where the symbols are found.
The logic for finding where a symbol is defined is very simple:
o Check X Server and libraries linked to it.
o Check all other modules in the module path, the script can handle
multiple module path, but it cannot ensure the driver is actually
loading a module.
It will also print a warning about multiple definitions.
I think I got all patches required for modules already commited,
but not for libraries (to define as weak some symbols also defined
in the X Server).
Points where special attention is required:
o Usage of LoaderSymbol() or dlsym. For this I just grep'ed everything,
and resolved by hand the missing symbols. Check hw/xfree86/i2c/*.h
for awesome samples, where it will cast to a function and call the
value returned by LoaderSymbol(). The ati multimedia drivers had
some very similar usage, but that should have been fixed now, only
missing feature there would be to be able to load the different
multimedia drivers, as they all provide symbols with the same name,
instead, it should provide a vector of driver callbacks. But see
xorg/driver/xf86-video-ati/src/theatre.h for a sample of how to
correct that usage of LoaderSymbol without breaking abi.
o Symbols also defined in libraries. Best example is libXfont. if
the X Server is plainly compiled with -fvisibility=hidden, it
will not say there are missing symbols and use the stubs in libXfont,
and the script will not even show the duplicated symbols (gcc can
make some very aggressive optimizations when a symbol is not
accessible from other shared objects, and just inline the "hidden"
function).
o Some symbols are a pain to find. My idea is to make some extra
patches just to make finding symbols (with your preferred text
editor :-) easier. The most important one is change things like:
-%<-
#define NAME(function)prefix ## name
type NAME(foo) { bar }
-%<-
to:
-%<-
#define BODY bar;
type prefix_foo { BODY }
-%<-
This also to handle the other common case of symbols "hard to find":
-%<-
type
#ifdef FOO
foo_name
#else
bar_name
#endif
(arguments) { baz }
I don't remember if there are any files generated on the fly now,
after the removal of mfb and xfxbpp
-%<-
o There are drivers that access "private" symbols, that is, symbols
not in /usr/include/xorg/*.h.
I don't have a tool to generate information about these, but once
I posted a list of symbols used by modules that are not in the
sdk, and symbols in the sdk that are not used by any module (the
script tells about symbols exported but not used by any module).
But when/if making symbols easier to find, generating such list
even by hand would not take much time.
In the worst case, the "framework" is still good to find things
like macros being compiled as a call to a function (due to not
including the header with macro definition), or just plain code
that calls functions no longer available.
Also, besides the temptation, I did not "ansify" the X Server
code to attempt to reduce patches size (it is still huge, besides
having one patch addressing a different problem).
Another detail is that it really needs some major review to
decide what really needs to be in the sdk, because to have it
properly implemented, everything in /usr/include/xorg/*.h should
be made available, and I think like only half of those symbols are
tagged _X_EXPORT.
Yet another detail, it may be a good idea to also use gcc's
visibility pragmas before inclusion of headers of external libraries.
My original patches to util/macros was to have a @@HIDDEN_SY
Re: X server 1.6 release schedule
Keith Packard schreef: > On Tue, 2008-11-18 at 14:42 -0500, Adam Jackson wrote: Hello, >> Can we define what RANDR 1.3 means? I think we're largely in agreement >> but I'd like it written down. > > I think RandR 1.3 includes: > > 1. Projective transforms > 2. Standard properties > 3. Per-CRTC DPMS controls > 4. Panning Will it also include the additional functions for the applications to know about the screens topology without re-scanning all the outputs. This was discussed with GTK leading to a flickering display each time a new application was started. Adam proposed this patch then: http://people.freedesktop.org/~ajax/patches/randrproto-1.3.patch Eric begin:vcard fn;quoted-printable:=C3=89ric Piel n;quoted-printable:Piel;=C3=89ric org:Technical University of Delft;Software Engineering Research Group adr:HB 08.080;;Mekelweg 4;Delft;;2628 CD;The Netherlands email;internet:[EMAIL PROTECTED] tel;work:+31 15 278 6338 tel;cell:+31 6 2437 9135 x-mozilla-html:FALSE url:http://pieleric.free.fr version:2.1 end:vcard ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X server 1.6 release schedule
On Tue, 2008-11-18 at 16:25 -0800, Keith Packard wrote:
> On Tue, 2008-11-18 at 18:23 -0500, Adam Jackson wrote:
>
> > Overscan correction? I don't think this counts as a subset of
> > projective transforms, but I could be wrong.
>
> No, not a part of projective transforms as it doesn't change the
> pixel->pixel mapping.
>
> It sounds useful; get some code together along with a spec update and we
> can ship it too.
I'm not hurting for it, so I'm not likely to kill myself to get it into
1.3. But, maybe! Or maybe someone else feels inspired.
I think it's most natural to do this as additional border fields in a
MODEINFO. Imagine a new definition:
MODEINFO { id: MODE
name: STRING
width, height: CARD16
dotClock: CARD32
hSyncStart, hSyncEnd, hTotal, hSkew, hBorder: CARD16
vSyncStart, vSyncEnd, vTotal, vBorder: CARD16
borderColor: COLOR
modeFlags: SETofMODEFLAG }
800x600 active area in a standard 1920x1200RB timing would then be:
{
xid,
"800x600u1920x1200",
800, 600,
154000,
1968, 2000, 2080, 0, 560,
1203, 1209, 1235, 300,
0x,
HSyncPositive, VSyncNegative
}
Note that borders are symmetric, and are specified as the distance
between timing active area and pixel active area.
There's sort of a tight binding in randr between (width,height) of a
mode and the CRTC dimensions, so while you _could_ do it the other way
around and give a plain 1920x1200 mode in the timings plus oh yeah
here's some border fields, it would make computing the rest of the world
more complicated.
Also you'd have to accomodate the older MODEINFO wire encoding for older
clients, but that's nothing new. Since you can't modify modes in place
this works out fine: a 1.2 client against an otherwise 1.3 server just
never sees the border fields, always create modes with 0 borders, and
applies modes including hidden border fields if the mode happens to have
them since you apply by XID not by full timing.
Then, of course, there's the problem of defining how bordered modes are
represented internally. The DisplayModeRec does have border fields, but
only in the hardware representation set, not in the user visible set.
- ajax
signature.asc
Description: This is a digitally signed message part
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X server 1.6 release schedule
On Wed, 2008-11-19 at 10:12 -0500, Adam Jackson wrote: > I think it's most natural to do this as additional border fields in a > MODEINFO. Imagine a new definition: I'd say adding a new border size and color request would be easier; you'd set the pending border size/color and then set the mode, just like properties. One question is whether we'd bother doing a driver-specific API or whether we'd just allocate the larger frame buffer, paint the border, and then just use a subset of that for the screen. We already separate out the projected size of the crtc (that portion of the screen represented in the crtc) from the mode size; that's necessary for rotation and other transforms. -- [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X server 1.6 release schedule
On Wed, 2008-11-19 at 13:55 +0100, Éric Piel wrote: > Keith Packard schreef: > > On Tue, 2008-11-18 at 14:42 -0500, Adam Jackson wrote: > Hello, > > >> Can we define what RANDR 1.3 means? I think we're largely in agreement > >> but I'd like it written down. > > > > I think RandR 1.3 includes: > > > > 1. Projective transforms > > 2. Standard properties > > 3. Per-CRTC DPMS controls > > 4. Panning > Will it also include the additional functions for the applications to > know about the screens topology without re-scanning all the outputs. > This was discussed with GTK leading to a flickering display each time a > new application was started. Adam proposed this patch then: > http://people.freedesktop.org/~ajax/patches/randrproto-1.3.patch Yeah, I didn't get that into the above list. I'm not sure I like the 'same information, but no query' plan; I don't think we need to return the possible mode information, just the current settings. -- [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X server 1.6 release schedule
On Wed, 2008-11-19 at 09:27 -0800, Keith Packard wrote: > On Wed, 2008-11-19 at 13:55 +0100, Éric Piel wrote: > > Keith Packard schreef: > > > On Tue, 2008-11-18 at 14:42 -0500, Adam Jackson wrote: > > Hello, > > > > >> Can we define what RANDR 1.3 means? I think we're largely in agreement > > >> but I'd like it written down. > > > > > > I think RandR 1.3 includes: > > > > > > 1. Projective transforms > > > 2. Standard properties > > > 3. Per-CRTC DPMS controls > > > 4. Panning > > Will it also include the additional functions for the applications to > > know about the screens topology without re-scanning all the outputs. > > This was discussed with GTK leading to a flickering display each time a > > new application was started. Adam proposed this patch then: > > http://people.freedesktop.org/~ajax/patches/randrproto-1.3.patch > > Yeah, I didn't get that into the above list. I'm not sure I like the > 'same information, but no query' plan; I don't think we need to return > the possible mode information, just the current settings. I don't think they're different. Either way, as long as it doesn't touch DDC we can work with it. - ajax signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X server 1.6 release schedule
On Wed, 2008-11-19 at 09:25 -0800, Keith Packard wrote: > On Wed, 2008-11-19 at 10:12 -0500, Adam Jackson wrote: > > > I think it's most natural to do this as additional border fields in a > > MODEINFO. Imagine a new definition: > > I'd say adding a new border size and color request would be easier; > you'd set the pending border size/color and then set the mode, just like > properties. One question is whether we'd bother doing a driver-specific > API or whether we'd just allocate the larger frame buffer, paint the > border, and then just use a subset of that for the screen. That works. I hadn't really thought through the implication that projective transforms meant modes != crtc sizes. The advantage to letting the driver do explicit border control is that it need only allocate enough memory for the active region. Besides the raw memory savings, it also means you save memory bandwidth (in the absence of framebuffer compression, but even with it when the screen changes), which in turn means lower power, and everybody loves that. But the other way means the driver need not have any explicit border knowledge, and that's also cool. Also you could do some really crazy hacks like specify the border as a pixmap instead of a color... Could do either one as a first pass, I suppose. - ajax signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X server 1.6 release schedule
On Wed, 2008-11-19 at 13:45 -0500, Adam Jackson wrote: > Could do either one as a first pass, I suppose. I'd suggest doing a DIX-level implementation today and working out driver hooks later on then. -- [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
