Re: [ANNOUNCE] xrdb 1.0.9
On Apr 06, 11 10:09:00 -0500, Pat Kane wrote: > Does Solaris 10 have that fault? > What about RHEL6? Sorry, I have no idea. > On Tue, Apr 5, 2011 at 11:46 AM, Matthias Hopf wrote: > > xrdb security issue; separate announcement follows. > > This fixes CVE-2011-0465. Matthias -- Matthias Hopf ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ m...@mshopf.de Phone +49-911-74053-715 __) |_| __) |__ R & D www.mshopf.de ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
[ANNOUNCE] X.Org security advisory: root hole via rogue hostname
X.Org security advisory, April 5th, 2011 root hole via rogue hostname CVE ID: CVE-2011-0465 Overview By crafting hostnames with shell escape characters, arbitrary commands can be executed in a root environment when a display manager reads in the resource database via xrdb. These specially crafted hostnames can occur in two environments: * Hosts that set their hostname via DHCP * Hosts that allow remote logins via xdmcp Impact -- Arbitrary (short) commands can be executed as root on affected hosts. With some display managers a working login is required (resource database is read upon login), with others no working login is required (resource database is read upon display manager start as well). Only systems are affected that 1) set their hostname via DHCP, and the used DHCP client allows setting of hostnames with illegal characters or 2) allow remote logins via xdmcp 1) requires either physical access to the network, or administrative access to the running DHCP server. 2) does not require physical access, if a regular account on a machine accepted by xdmcp is available, but describes a case that is considered insecure nowadays. Affected versions - xrdb up to including 1.0.8 X11R7.6 (latest release) includes xrdb 1.0.7 Fix --- This issue has been fixed with git commit 1027d5df07398c1507fb1fe3a9981aa6b4bc3a56 http://cgit.freedesktop.org/xorg/app/xrdb/commit/?id=1027d5df07398c1507fb1fe3a9981aa6b4bc3a56 A fix of this vulnerability is included in xrdb 1.0.9. This issue was found by Sebastian Krahmer from the SUSE security team. Thanks Matthias Hopf pgpIGrYFehkKV.pgp Description: PGP signature ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
[ANNOUNCE] xrdb 1.0.9
xrdb security issue; separate announcement follows. This fixes CVE-2011-0465. Matthias Hopf (2): Create shell-escape-safe cpp options in the non-pathetic-cpp case. Bump to 1.0.9 git tag: xrdb-1.0.9 http://xorg.freedesktop.org/archive/individual/app/xrdb-1.0.9.tar.bz2 MD5: ed2e48cf33584455d74615ad4bbe4246 xrdb-1.0.9.tar.bz2 SHA1: efa5f2420411988d6a6e142934393fd272507857 xrdb-1.0.9.tar.bz2 http://xorg.freedesktop.org/archive/individual/app/xrdb-1.0.9.tar.gz MD5: cc66bd89cd830c8b4c839421397457ac xrdb-1.0.9.tar.gz SHA1: 0beefc6dc4fa99bd673b58ed5b2b13d741621720 xrdb-1.0.9.tar.gz pgpOcVSDzQo90.pgp Description: PGP signature ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Respository vandalism by r...@...fd.o
On Nov 23, 10 22:56:52 +, Alan Cox wrote: > > It's on a separate branch, not master. (Doesn't mean it's right, just > > that it's not actually going to cripple anything or waste time for anyone > > who doesn't ask for it.) > > And how many other un-noticed commits did this person make ? Until you > know that you have to assume a complete compromise. Luckily, git makes this difficult. At least as long as git histories are repeatedly checked (which they are for the main trees), a git fsck should find any inconsistencies, and you should get broken fast-forwards. Not that this makes the fraud any better. Matthias -- Matthias Hopf ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ m...@mshopf.de Phone +49-911-74053-715 __) |_| __) |__ R & D www.mshopf.de ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: randr: "reverse panning"
On Feb 25, 10 01:36:53 +0200, Andriy Gapon wrote: > Sorry for not following the latest RandR developments, but let me ask. > Does RandR support setting a monitor mode to NxM resolution (e.g. its native > resolution) while setting its 'effective pixel resolution' (a term just > invented > by me) to PxR where P <= N and/or R <= M? > In other words, can I have a monitor set to its native resolution while using > only a portion of its pixels as if it had some other, smaller resolution. If you choose a resolution for a monitor, then by *definition* the scanout area has to be scanned out. Which means, you cannot allocate less pixels than are actually shown. You might have a chance, though, to create a modeline manually, that uses the timings for the native mode, but is only active for a smaller number of pixels. Whether this works with your monitor is doubtful, but it might be worth a try. Most graphics cards can be programmed to scan out a larger area, but only access the framebuffer for a smaller subset - which would be exactly what you want. AFAIR there is no API to provide that information to the driver, or for the driver to provide information about this ability to the server. What you probably *really* want is working shatter support. Which is still in the flux. Matthias -- Matthias Hopf ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ m...@mshopf.de Phone +49-911-74053-715 __) |_| __) |__ R & D www.mshopf.de ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [Pixman] [PATCH] Fix server crash in pixman (to be discussed)
On Mar 24, 10 19:19:15 +0100, Soeren Sandmann wrote: > > However, what happens if the code would have been compiled with -NDEBUG? > > Is the code path stable with empty regions? If it is, it can be argued > > that the patch is not necessary, but it could also be argued that the > > assert() shouldn't have been there in the first place. > > Who knows? Who knows if it's stable even *with* the patch? That's why > I don't want it in for 0.18.0. Right. I just want to indicate that just disabling the assert()s typically is no "solution" for issues like this. > > That sounds more realistic. However, we don't have any other issues with > > assert()s, and there is a slim chance that this backport introduces > > additional regressions (asserts with side effects etc.). > > If it were *my* enterprise product, I'd definitely get rid of the > assertions, because they are known to take down the X server in > various situations. That's your call of course. If it was *my* enterprise product, I would've done quite a number of things differently ;-) I'm not entirely sure ATM, but you have a point. > As of 0.17.6 the assertions are not even enabled in unstable releases > because the only result were that they get triggered by the same old X > server issues, which just causes people to not test the pixman > releases. Which is problematic, because in this case the Xserver isn't fixed. No, I don't have a good solution to this dilemma. Matthias -- Matthias Hopf ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ m...@mshopf.de Phone +49-911-74053-715 __) |_| __) |__ R & D www.mshopf.de ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [Pixman] [PATCH] Fix server crash in pixman (to be discussed)
On Mar 24, 10 18:28:07 +0100, Soeren Sandmann wrote: > Please note that while pixman is not as strict as the X server in who > can push to the repository, it is not a complete free-for-all. > Committing small, obvious patches that fixes typos or oversights is > fine, but don't commit non-obvious stuff without sending it to the > mailing list and giving people time to comment on it. Ok, just the comment from Jonathan indicated to me that I should commit. > When we are this close to stable release, we need to be even more > careful about what goes in. Patches committed between now and next > week will likely ship without no testing at all. It definitely did help here. So there's at least minimal testing :) > This patch in particular, I don't think shold ship with no testing at > all. So please revert it, and we can consider it again for 0.19.x. I'm fine with that if you consider it problematic. Given that the situation it changes should actually not occur at all, I doubt there's any fallout, though. > - Why are you seeing an assert in the first place? > > The asserts have been disabled since 0.16.4/0.17.6 because pixman > shouldn't take down the X server with asserts for things that would > otherwise be harmless. Apparently we're still using 0.16.0 in SLE11SP1. So that explains. I double checked that there were no related changes in the region code before fixing. However, what happens if the code would have been compiled with -NDEBUG? Is the code path stable with empty regions? If it is, it can be argued that the patch is not necessary, but it could also be argued that the assert() shouldn't have been there in the first place. > If you are using an older version than those in SLES, then you might > want to either upgrade to 0.16.4, or backport No chance. We are version and feature freeze for quite some time now. Time cycles are much different in enterprise products :-/ Especially in SLE11SP1, as changes to SLE11 should be as minimal as possible (and SLE11 is over a year old). >ec6de472d042bec05aaa53f9d14bfbe23edbe01e That sounds more realistic. However, we don't have any other issues with assert()s, and there is a slim chance that this backport introduces additional regressions (asserts with side effects etc.). > - How does the degenerate region get created? Unfortunately I don't know the offending Xserver code by heart. It probably has to be reviewed, I guess there are sleeping dragons there. > - The patch does not look wrong to me - a region with empty extents > should probably be considered empty rather than degenerate. However, > unless this issue is truly causing crashes, changing it is the kind It is definitely causing crashes here, reproducibly, but only on very rare occasions (of which we run into one during installation :o] ) > candidate and a stable release. Did you carefully review all the > code to make sure it always uses PIXMAN_NIL to check for empty > regions? No, but that shouldn't change behavior. Unless a single code snippet uses both PIXMAN_NIL and handcoded tests at the same time. > - Finally, we need much more detail in commit messages than "Fixes > Novell bug xx". Understood. I thought the code change to be trivial in itself. > Is that even a public bug? I couldn't figure out how to look at > it. I did not create a Novell Login though. Unfortunately, no. Not that I did notice before, oops. You tend to miss those things if you're working with credentials set all the time... It doesn't contain much more information than the backtrace I published, though. Matthias -- Matthias Hopf ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ m...@mshopf.de Phone +49-911-74053-715 __) |_| __) |__ R & D www.mshopf.de ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [Pixman] [PATCH] Fix server crash in pixman (to be discussed)
On Mar 24, 10 13:25:13 +0200, Jonathan Morton wrote: > Drawing a string containing spaces but also other characters would > result in a non-degenerate region, presumably. So the bug might be > triggered by a string containing only a space. Sounds reasonable. > It may be appropriate to use a "belt and braces" approach here - prevent > the degenerate regions from being created, *and* have the PIXREGION_NIL > macro handle them. Also sounds reasonable. Glyphs are apparently only rendered in a few places in the Xserver, so this should be doable. Exa apparently already handles this correctly. Matthias -- Matthias Hopf ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ m...@mshopf.de Phone +49-911-74053-715 __) |_| __) |__ R & D www.mshopf.de ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
[PATCH] Fix server crash in pixman (to be discussed)
The following patch fixes Novell bug 568811: VNC Installation aborts right in the middle due to an assertion in Xvnc/libpixman The bug seems occur only on *very* special occasions (in this case, only in SLES, but *not* in SLED, which is based on the same code basis...). Backtrace looks as follows: #2 0xb71f7baa in __assert_fail () from /lib/libc.so.6 #3 0xb781feab in pixman_region_append_non_o (y2=, y1=, r_end=, r=, region=) at pixman-region.c:670 #4 pixman_op (y2=, y1=, r_end=, r=, region=) at pixman-region.c:996 #5 0xb7820dbe in pixman_region_union (new_reg=0x82ee57c, reg1=0x82ee57c, reg2=0xbfd77c90) at pixman-region.c:1439 #6 0x080f023b in miUnion (newReg=0x82ee57c, reg1=0x82ee57c, reg2=0xbfd77c90) at miregion.c:1005 #7 0x0806eebe in rfbComposite (op=12 '\f', pSrc=0x8297c08, pMask=0x0, pDst=0x82a7a00, xSrc=0, ySrc=0, xMask=0, yMask=0, xDst=20, yDst=8, width=0, height=0) at draw.c:1805 #8 0x0815ddad in CompositePicture (op=12 '\f', pSrc=0x8297c08, pMask=0x0, pDst=0x82a7a00, xSrc=0, ySrc=0, xMask=, yMask=, xDst=, yDst=, width=0, height=0) at picture.c:1675 #9 0x0815a1bf in miGlyphs (op=3 '\003', pSrc=0x82f0810, pDst=0x82a2808, maskFormat=0x822f8b8, xSrc=0, ySrc=0, nlist=1, list=0xbfd782a8, glyphs=0xbfd77ebc) at glyph.c:726 #10 0x0815a462 in CompositeGlyphs (op=, pSrc=0x82f0810, pDst=0x82a2808, maskFormat=0x822f8b8, xSrc=0, ySrc=0, nlist=1, lists=0xbfd782a8, glyphs=0xbfd77ea8) at glyph.c:632 #11 0x0816741e in ProcRenderCompositeGlyphs (client=0x829a860) at render.c:1462 #12 0x08160895 in ProcRenderDispatch (client=0xfcf) at render.c:2089 #13 0x0809bb47 in Dispatch () at dispatch.c:456 #14 0x080b24ba in main (argc=21, argv=0xbfd78704, envp=Cannot access memory at address 0xfd7 What happens is that an assert in pixman_region_append_non_o() fails, because the region reg2 is degenerated. PIXREGION_NIL as is doesn't detect this region as being empty, presumably because this should never ever happen. The patch is a workaround by enhancing PIXREGION_NIL to detect degenerated regions. However, the real reason is probably shaded by this commit. Reading the source in render/glyph.c in the Xserver it seems that the glyph to be rendered is empty (glyph->info.width=glyph->info.height=0). Question is now whether that is allowed or not. If it is question remains on which level this should be fixed. If it is not, question remains why this could happen. Thanks Matthias -- Matthias Hopf ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ m...@mshopf.de Phone +49-911-74053-715 __) |_| __) |__ R & D www.mshopf.de >From ebc92a0d70054746ac51996a2cfa44dfc9cc79fe Mon Sep 17 00:00:00 2001 From: Matthias Hopf Date: Wed, 24 Mar 2010 12:00:21 +0100 Subject: [PATCH] Improve PIXREGION_NIL to return true on degenerated regions. Fixes Novell bug 568811. --- pixman/pixman-region.c |6 +- 1 files changed, 5 insertions(+), 1 deletions(-) diff --git a/pixman/pixman-region.c b/pixman/pixman-region.c index a6a4005..179241d 100644 --- a/pixman/pixman-region.c +++ b/pixman/pixman-region.c @@ -69,7 +69,11 @@ #include #include "pixman-private.h" -#define PIXREGION_NIL(reg) ((reg)->data && !(reg)->data->numRects) +#define PIXREGION_NIL(reg) (((reg)->data && !(reg)->data->numRects) || \ + (! (reg)->data &&\ + (reg)->extents.x1 == (reg)->extents.x2 && \ + (reg)->extents.y1 == (reg)->extents.y2)) + /* not a region */ #define PIXREGION_NAR(reg) ((reg)->data == pixman_broken_data) #define PIXREGION_NUMRECTS(reg) ((reg)->data ? (reg)->data->numRects : 1) -- 1.6.0.2 ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Re: The State of The X.Org Foundation 2010
On Feb 25, 10 03:38:42 -0800, Barton C Massey wrote: > Sorry, that previous paragraph wasn't as clear as it could > be. At the beginning of 2009, Keith stepped down from the > Board. He then ran again and was elected at the beginning > of 2010. Welcome back, Keith! Ah, yes, this absolutely makes sense now. Thanks Matthias -- Matthias Hopf ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ m...@mshopf.de 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: The State of The X.Org Foundation 2010
On Feb 20, 10 15:01:50 -0800, Barton C Massey wrote: > The 2009 Board election was once again delayed, and > completed in mid-February 2010. This is unfortunate, > and further work needs to be done to ensure that the > 2010 and ongoing elections can be held in a timely and > regular manner. This election was the first in quite a > while in which the restriction in the X.Org Bylaws that > only two people from a given organization can be on the > Board simultaneously was an issue. The issue was > resolved by Keith Packard stepping down from the Board, > leaving only two Intel representatives. I'm standing puzzled, because in your later mail about the voting results you write: > Thus, the four officers that will join the Board for > two-year terms starting in 2010 are Alex Deucher, Keith > Packard, Matthieu Herrb, and Matthias Hopf. Eric Anholt > will have a one-year term to fill the vacancy left by the > resignation of Daniel Stone. To me this sounds contradicting about Keith - but maybe I don't get the complete picture yet. Thanks Matthias -- Matthias Hopf ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ m...@mshopf.de 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: Board voting ends today, but...
On Feb 19, 10 17:01:15 +, Daniel Stone wrote: > > I didn't know it was that much. Now thinking of it I do not remember > > what we used PayPal for... > > Clare College would only accept one large group booking for > accommodation (and accommodation is ridiculously expensive and generally > quite hard to find in Cambridge outside the colleges), so we decided to > book for most everyone coming to the conference and pay Clare ourselves, > then collect the money off everyone who wasn't sponsored. At first, we > tried to use PayPal for this. Ah, thanks! > > Anyway, I'm rather interested what the Brazilian bank mafia had to do > > with all this? I doubt anybody thought these scaming mails were for > > real and something to be worth investing?!? > > Haha, of course not. :) It was wiring money to two of the Brazilians we > sponsored to come to XDS 2007. 5k? OMFG. Well, ok, it's only 2,5k per person, and currently I don't know what flights to Brazil cost... sounds a bit much, but if everything was delayed due to issues (or if this includes a second, successful, attempt at getting the tickets) it's reasonable. Thanks again, Daniel Matthias -- Matthias Hopf ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ m...@mshopf.de 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: Board voting ends today, but...
On Feb 18, 10 17:27:24 -0800, Stephane Marchesin wrote: > Considering that: > - there is so much money in the bank (about 3 times what you need for > XDS 2007, *hint* *hint*), Which means that 2013 we are out of money :-P > - giving wide sponsorship makes these conferences better by gathering > more people > - the current economy does not help with funding conference trips > neither for the professional devs nor for the spare-time devs, > my opinion, and the point I was trying to make, is that we should have > more like that one... Good point. I should know that, being employed by such a company (with now *very* restricted travel budget). Matthias -- Matthias Hopf ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ m...@mshopf.de 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: Board voting ends today, but...
On Feb 18, 10 21:45:07 +, Daniel Stone wrote: > * THIS IS ONLY MY RECOLLECTION FROM A TWO-MINUTE SCAN OF EMAIL. * > * DO NOT TAKE IT AS GOSPEL, DO NOT RELY UPON IT AS ABSOLUTE TRUTH.* Thanks for dealing with this so quickly, Daniel! > As far as I can tell (and I've not looked hard, because I'd like to > escape the office early), XDS 2007 cost $US10k for the venue, around > $US24k for travel sponsorship (no joke) As long as X.org has enough money I do not care too much about how much money is spent for helping people getting to the event. I think the 2007 event was a big success, so money well spent. That said, with the current funding we cannot do the same for another 10 years :-] > , and something like $US5k lost > to PayPal (they decided we were scammers and took our money) as well as > around $US5k that vanished into the Brazilian banking system, which > gives us $US45k for one conference. Jikes! I didn't know it was that much. Now thinking of it I do not remember what we used PayPal for... Anyway, I'm rather interested what the Brazilian bank mafia had to do with all this? I doubt anybody thought these scaming mails were for real and something to be worth investing?!? > If you feel this is unacceptable and are looking to assign blame, the > mail archives back me up that the entire thing was entirely my idea, and > every single costing and proposal came from myself. Nobody's gonna blame you, Daniel. You did a lot of the work back then, and I assume others wouldn't make the same mistakes, but different ones :--] I think the general feeling is that the events - well - happened, not a such big deal, but transparency is severely lacking. I'm writing in present tense, even though the clouds are already starting to lighten up. Matthias -- Matthias Hopf ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ m...@mshopf.de 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.Org Foundation Board of Directors 2010 Election
On Feb 16, 10 11:54:35 -0600, Jeremy White wrote: > Keith Packard wrote: > > On Tue, 16 Feb 2010 17:54:56 +0100, Matthias Hopf wrote: > >> But something like $100 / month sounds like a reasonable upper limit for > >> me, and you should actually get by for half of it. > > We've got three servers and a switch; the 3U servers are $1200/year, and > > the 2U server + switch is $600. > > For the record, I think the assertion that getting rackspace and bandwidth > for 3 dedicated servers in a facility that's reliable, convenient, > and likely to be around in 6 months for $50/month is a fantasy. For the record, hosteurope.de is one of the longest running provider I know in Europe, not exactly the cheapest, and you get a rented server with hardware raid for EUR 59 per month. Given my experience 1 EUR is approx. equal with 1 US$ in the computer business (yes, it's not the exchange rate), but even if you take the direct exchange rate this is easily managable for $100 per month. And I didn't exactly search for long. Haven't looked for bandwidth flatrates yet, though. And of course, I don't know the hardware setup we have. We probably have more RAM and more disk space. That said, I'm perfectly fine with the current situation. I just wanted to know what we're paying this for. > Of course, shifting away from dedicated servers to an alternate > strategy is certainly something that may well be worth exploring, > for reasons beyond cost. What alternative strategy would that be? I'm always interested, but I doubt anybody has the resources to look into anything groundshaking new. Besides, we have a number of projects relying on freedesktop.org. > But I just wanted to say that the current spending looks quite > reasonable to me. And I also know how thankless a task it is to run > a server such as x.org, so let me officially say - 'thanks!' to the > folks that are doing it... :-) Definitely! Matthias -- Matthias Hopf ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ m...@mshopf.de 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.Org Foundation Board of Directors 2010 Election
On Feb 16, 10 09:20:44 -0800, Keith Packard wrote: > On Tue, 16 Feb 2010 17:54:56 +0100, Matthias Hopf wrote: > > > But something like $100 / month sounds like a reasonable upper limit for > > me, and you should actually get by for half of it. > > We've got three servers and a switch; the 3U servers are $1200/year, and > the 2U server + switch is $600. Thanks for the insight, Keith! These prices look reasonable for rented servers. Question is rather 1) are the servers in X.org's possession or rented 2) why we had this many servers at all 3) why are 3U servers needed (drives, or are they just in the possession of Xorg - in that case buing some new cheaper to host hardware might be interesting) Going forward it's probably a good thing that we have enough server power, and I assume it's just the good ol' "nobody has any time left to work on that" issue. :-/ Matthias, being a perfect example of the later -- Matthias Hopf ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ m...@mshopf.de 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.Org Foundation Board of Directors 2010 Election
On Feb 16, 10 16:45:09 +, Alan Cox wrote: > > On Feb 16, 10 07:26:35 -0800, Keith Packard wrote: > > > Our outstanding obligations today are MIT hosting for this year ($3000) > > > and travel expenses for FOSDEM 2010 ($660). > > > > Not that it matters too much, but $3000 sounds pretty hefty for hosting. > > OTOH I don't know hardware, bandwidth, or what is included (backup etc.). > > Seems pretty extrodinary. Exactly what can't say bluehost provide at > $3.95 a month that MIT can at $250/month ? I very much doubt you get a full server for $4 a month. A virtual, yes, but freedesktop.org is much to frequented for a virtual host. But something like $100 / month sounds like a reasonable upper limit for me, and you should actually get by for half of it. Unless I completely miss something. Matthias -- Matthias Hopf ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ m...@mshopf.de 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.Org Foundation Board of Directors 2010 Election
On Feb 16, 10 07:26:35 -0800, Keith Packard wrote: > Our outstanding obligations today are MIT hosting for this year ($3000) > and travel expenses for FOSDEM 2010 ($660). Not that it matters too much, but $3000 sounds pretty hefty for hosting. OTOH I don't know hardware, bandwidth, or what is included (backup etc.). Is there any list what this service includes? Thanks Matthias -- Matthias Hopf ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ m...@mshopf.de 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: My pretty unusual XRandR use case, where nobody but you has a chance of solving it. ^^
On Dec 26, 09 06:33:43 +0100, Navid Zamani wrote: > Hello, > > I got a pretty unusual setup here: > I have a 4:3 CRT running at 1600x1200+0+0 with 101 DPI, > and a 16:9 projector running at 1024x768+1600+431 (yes, that’s > anamorphic, aka. with non-square pixels) which of course has a > projection size of something around 3m in width (I’d measure it out later). > > So I have two very different DPIs and most importantly: Two different > pixel formats (square and non-square). In short: such a scenario is completely unsupported. > How in the world would I set that up properly? > --fbmm does only allow a global setting, and does not seem to do > anything anyway (tried 400x100 as a parameter, with no changes). > --dpi also is only global, but does not even allow different settings > for horizontal and vertical. This is because the Xserver has only the notion of number of pixels and screen size in cm. DPI can be calculated by these values, thus you either set framebuffer size in cm or dpi, the other one comes for free. Also note the singular (screen size in cm). There's no such thing as different dpi values per output. Would require even protocol changes (what do you do if your window is for ones half on one screen and one half on the other?). Besides - why would anyone want to use 1024x768 on a 16:9 projector?!? Or does the projector really have an anamorphic lens? Matthias -- Matthias Hopf ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ m...@mshopf.de 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: how to read EDID/xrandr
On Oct 12, 09 09:49:14 -0400, Alex Deucher wrote: > On Mon, Oct 12, 2009 at 9:05 AM, Éric Piel wrote: > > Op 11-10-09 03:35, Ondrej Balaz schreef: > >> Hi, > >> is it possible to get edid info (especialy vendor and product id) for > >> each of xrandr screens through X11 api? > >> > >> I'm creating utility to remember various devices connected to VGA output > >> of my laptop (their mode/resolution, position etc.). AFAIK there is no > >> better identificator than vendor+product_id pair. I can see both > >> informations for various devices in my Xorg.0.log but I don't know how > >> to "reaccess" them (if it's possible). > > Sounds like a neat utility program. Would you mind posting an > > announcement when it's working? > > > > Here, with the intel driver, I can see the edid of each screen in the > > EDID_DATA property by doing: > > xrandr --verbose > > All randr 1.2 drivers expose the edid this way. Actually, this is exposed by the Xserver itself. Please note that with RandR 1.3 this property was renamed to just EDID in the big property unification change. Matthias -- Matthias Hopf ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ m...@mshopf.de Phone +49-911-74053-715 __) |_| __) |__ R & D www.mshopf.de ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[ANNOUNCE] xf86-video-radeonhd 1.3.0 Release
Announcing the 1.3.0 Release of the xf86-video-radeonhd driver. RadeonHD is the X.org X11 driver for AMD GPG (ATI) r5xx/r6xx/r7xx chipsets. The development is driven by a community of open source developers, supported by Novell and AMD at the time of writing. AMD provides free documentation for the chipsets. Note the wiki on http://wiki.x.org/wiki/radeonhd Version 1.3.0 improvements: - Added support for RV740, M92, M93, M97. - Added support for HDMI audio on RS690 and R700. - Added support for power management. - Implemented almost correct analysis of PowerPlay AtomBIOS tables. - 2D acceleration (EXA) is enabled by default now, except on RV740. - Backlight handling finally fixed - compatible with xbacklight 1.1.1. - Overhaul of memory controller setup. Fixes many "MC not idle" issues. - Overhaul of cursor handling. Fixes most cursor bugs. - Selectable color space for XVideo on R6xx/R7xx. - Tons of bug fixes (DDC, EXA, LUT, RandR, AtomBIOS). - More quirk table entries. - Shave support (cleaner compilation output). - All warnings fixed. - Some start of Developer's documentation in README.coding. git tag: 1.3.0 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-radeonhd-1.3.0.tar.bz2 MD5: 7b6641aa9d836f1621b9b220ad6771b8 xf86-video-radeonhd-1.3.0.tar.bz2 SHA1: 4cdcdbcdc6ec7cd4caa19afdbfc34a8bec461f56 xf86-video-radeonhd-1.3.0.tar.bz2 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-radeonhd-1.3.0.tar.gz MD5: d635f5f0f6ab821662502ce87dc7077a xf86-video-radeonhd-1.3.0.tar.gz SHA1: fd85910b540e64639155f94d136bd07c314f0bf5 xf86-video-radeonhd-1.3.0.tar.gz git ShortLog: - Alex Deucher (6): Fix build on systems without pci_device_enable() RS690: fix EXA corruption Fix build on systems without pci_device_enable() Fix scissor offsets for r5xx in last patch r7xx: add some new pci ids rs880: enable accel Christian Koenig (2): Initial RS690 HDMI Audio support. R700 HDMI audio support. Christian König (1): Silence audio stream option. Dave Airlie (3): radeonhd: update for resources/RAC API removal radeonhd: further RAC/resources changes radeonhd: change to using ABI version check David Morrison (1): LUT: Fix syntax error in 59085c4a Egbert Eich (12): Remove superfluous function arguments. Spelling fixes. Move test for backlight support enabled to proper place. Reenabling AtomBIOS controlled backlight. Add better fallback heuristics for acceleration methods. Clean up most warnings. Add ACPI controlled Backlight support for Linux. PM: Removed unnneeded define. ID: Added quirk entry for HIS Excalibur Radeon XT1650 Pro IceQ 256M Properites: Get HW for Backlight setting on every query. Improve test for disabled differential clock driver. Improve DAC load detection on RS780. Florian Forster (1): man/radeonhd.man: Fix two typos. Hans Ulrich Niedermann (2): Fix RHDRegWrite macro invocation breakage Hide README, radeon.man non-updates if --enable-shave Jakub Zawadzki (1): rhd_conntest: mmap() returns -1 on error, not NULL Javeed Shaikh (1): Xv: Fix YUV scaling and use Rec709 coefficients Luc Verhaegen (4): Cursor: fix logic error in cursor visibility checking. DRI: Fix VBlankInterrupt setting when not using RandR1.2. Revert "More idle/flush swaps." Revert "Fix softlocks on rs690. Idle commands have to be flushed to be of any use." Marc Dietrich (2): silence some compiler warnings Fix softlocks on rs690. Idle commands have to be flushed to be of any use. Marvin (1): Port lockup fix from radeon Matthias Hopf (74): Extend ugly hack for CARD64 to rhd_mc.h. Consolidated chip identifiers. Extend ugly hack for CARD64 to rhd_mc.h. This time actually working. FB mapping cleanup didn't reflect changes to allocation. Fixes #21233. Fix #13405: Cursor corruption Nuke some trailing whitespace. man: cleanup rhd_dump: move pci_device_enable to correct case (pciaccess) utils: Only allow -e if pci_device_enable() is available. modes: Fixup broken panel modes if possible Fix switch construction in LVDSPropertyControl Add quirk entry for 0x7146:0x174B:0x0940. Bug #21947. Add some more PCI Ids, improve RV740 handling, fix descriptions. Add AtomBIOS based static powermanagement enablement Initialize fresh connector object correctly in AtomBIOS case. Add quirk table entry for Asus F3JR. Adapt for nuked xf86LoaderReqSymLists() in Xserver 1.6.99.1. randr: Remove useless error messages when fetching unknown/invalid properties. Move setting of Private->Modes to correct place. Refactor AtomBIOS option handling. randr: Add AtomBIOS property for on-the-fly setting. Expe
Re: fd.o services outage, annarchy $HOME lost
On Sep 30, 09 15:34:47 -0700, Daniel Stone wrote: > Again, please accept our apologies. The decision was made a long time > ago to not back up $HOME, and it was mentioned a few times, but I don't have any issues about $HOME not being backed up (besides I didn't know that, but again, it's a free service, so I do not *expect* anything). But I would like to know the reasoning behind that. Is /home notoriously flooded with short-living big-sized files, or has this something to do with local law, or what? Thanks for your work, guys, to reenable the service. Matthias -- Matthias Hopf ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ m...@mshopf.de 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: [Q] Xorg VNC driver?
On Sep 23, 09 14:33:24 -0500, Pat Kane wrote: > On Wed, Sep 23, 2009 at 8:46 AM, Matthias Hopf wrote: > > Sorry, porting was only to 1.6.3.901 (just noted that). However, they > > will probably a good start. > They provide a very good staring point and have saved me a lot of > work, thank you. > > I think the the mouse init code, init.c, needs to look somthing like > the attached snippet > of code (sorry I can not make patches yet). Does that look right? It doesn't look wrong (though I'm unsure how z axis i.e. mouse wheel is handled, and in the code I can only see handling of 3 buttons and 2 axes), but I'm not exactly fluent in that area. I did the port without too much thinking, and was happy that it actually worked with 1.6.3.901... CU Matthias -- Matthias Hopf ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ m...@mshopf.de 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: XbkGetControls() fails...
On Sep 24, 09 15:37:58 +1000, Peter Hutterer wrote: > On Wed, Sep 23, 2009 at 03:16:38PM +0200, Matthias Hopf wrote: > > With the current Xserver XbkGetControls() fails with XkbBadKeyboard. > Tricky. xkb.device_spec is 0, which used to be the core keyboard (up to > 1.5). Now 0 is a reserved ID. If you add That explains everything. >xkb.device_spec = XkbUseCoreKbd; > before the call it picks the right keyboard. Strictly speaking, the code > sample was never valid, it just happened to work. > > Is this one of your test programs or a client that actually failed? Just a test program for printing out accessibility settings (I couldn't find *anything* in the X suite, so I coded up my own, because something in modern desktops always turned XkbAccessXKeysMask on, even though we wanted to have it off by default). Given that I had no clue of the whole subsystem it's fascinating I ever got it to work :-) Thanks a lot Matthias -- Matthias Hopf ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ m...@mshopf.de 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: [Q] Xorg VNC driver?
On Sep 23, 09 08:09:58 -0500, Pat Kane wrote: > Has anyone ported xf4vnc to xorg-server 1.7 (1.6.99)? Sorry, porting was only to 1.6.3.901 (just noted that). However, they will probably a good start. Matthias -- Matthias Hopf ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ m...@mshopf.de Phone +49-911-74053-715 __) |_| __) |__ R & D www.mshopf.de ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
XbkGetControls() fails...
With the current Xserver XbkGetControls() fails with XkbBadKeyboard. Is this a known issue? Is the call deprecated? -> cut <- XkbDescRec xkb; Display *disp = XOpenDisplay (disp_name ? disp_name : ":0"); memset (&xkb, 0, sizeof(xkb)); ret = XkbGetControls (disp, XkbAllControlsMask, &xkb); -> cut <- CU Matthias -- Matthias Hopf ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ m...@mshopf.de Phone +49-911-74053-715 __) |_| __) |__ R & D www.mshopf.de ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[ANNOUNCE] xrandr 1.3.2
Small update, being a little more verbose if mistakes are made. Bart Massey (2): Warn if one of the outputs given did not exist changed a bunch of string to number conversions for reliability Matthias Hopf (2): Add missing 'static's to get rid of warnings. Bump to 1.3.2 git tag: xrandr-1.3.2 http://xorg.freedesktop.org/archive/individual/app/xrandr-1.3.2.tar.bz2 MD5: 2cb19bb1c19ccf77c40032b03dbe06f0 xrandr-1.3.2.tar.bz2 SHA1: 0e49b0a0889ae8a590452c6cd0d60a2253a8d940 xrandr-1.3.2.tar.bz2 http://xorg.freedesktop.org/archive/individual/app/xrandr-1.3.2.tar.gz MD5: 5519a9ba1ece9c040a83f6f5e47946c7 xrandr-1.3.2.tar.gz SHA1: e84d5b39a39b722473bb1414d9c391622ed2df8b xrandr-1.3.2.tar.gz Matthias -- Matthias Hopf ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ m...@mshopf.de Phone +49-911-74053-715 __) |_| __) |__ R & D www.mshopf.de pgpxspPRiOYC3.pgp Description: PGP signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [ANNOUNCE] libSM 1.1.1
On Aug 07, 09 16:08:03 +0200, Rémi Cardona wrote: > This being my first Xorg release, I apologize in advance for any screw ups. No big issue, but announcement mails should be gpg signed. Thanks Matthias -- Matthias Hopf ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ m...@mshopf.de Phone +49-911-74053-715 __) |_| __) |__ R & D www.mshopf.de ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[ANNOUNCE] xrandr 1.3.1 Release
The last couple of fixes hanged long enough to be declared good, and at least the server grab fix is important enough to justify a release. Federico Mena Quintero (1): bfo#22864 - grab the server around all modifications to CRTCs Matthias Hopf (3): Report program version as well with --version. Fix missing prototype warning. Bump to 1.3.1 Éric Piel (1): xrandr: Document --nograb option GIT tag: xrandr-1.3.1 ftp://ftp.freedesktop.org/pub/individual/app/xrandr-1.3.1.tar.bz2 MD5: b1a77afa37d845bccc6726e2891fc7f2 xrandr-1.3.1.tar.bz2 SHA1: ba30219c6158eaf077bebd80107568867ef9d926 xrandr-1.3.1.tar.bz2 ftp://ftp.freedesktop.org/pub/individual/app/xrandr-1.3.1.tar.gz MD5: f8825747b3f9729d0e645b52d31979ed xrandr-1.3.1.tar.gz SHA1: 4c5ab4ef0e2dc2e260d40d6d8fa222198ccc81a7 xrandr-1.3.1.tar.gz Matthias -- Matthias Hopf ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ m...@mshopf.de Phone +49-911-74053-715 __) |_| __) |__ R & D www.mshopf.de pgp3RgAwktvpf.pgp Description: PGP signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: proportional panning
On Jun 28, 09 04:41:54 +0100, David De La Harpe Golden wrote:
> 2009/6/8 Matthias Hopf :
> > Yes, you're right - I forgot how it was on the Amiga. Shame on me.
> > You're more than welcome to add this to the panning code.
>
> Turns out doing the panning itself is the easy bit, there's extending the
> randr
> protocol to include a panning mode field and xrandr command line tool to
> grok it too to worry about...
Yes, there is no flags field or something similar so far. Either means
that there should be an additional call, or this could be implemented
with a (to be standardized) property for the moment. In the end this
probably should be part of the protocol.
> Attached please find an initial patch anyway, though only settable
> from xorg.conf
> as it stands owing to the above, just adds another field to the end of
> the lengthy
> "Panning" option string:
>/b (or nothing - default) for border push,
>/l for the proportional panning.
Reasonable enough for the beginning.
> Note that the border values are still used and relevant in the proportional
> code path:
> 1. as you get close to the edge of the crtc it can be nice to
> have unpanned zones to facilitate window placement, it made
> sense to reuse the border fields, use positive
> border values to have such zones, as in the first example below.
Agreed.
> 2. it turns out negative border values also allow a potentially quite
> useful effect with the proportional panning mode:
> Say you had two 1024x768 monitors, one above the other. You want
> a larger virtual desktop, say 2048x3072. Well, you can e.g. do the
> following, and as you pan around the edges will line up on
> both heads at all times, which is neat:
Interesting. Wouldn't have thought of that :-)
Might be interesting to add this to the manual as an example (if it
isn't already).
> + switch (pm) {
> +case 'l':
> + output->initialPanningMode = XF86CrtcPanningModeLinear;
> + break;
> +case 'b':
> +default:
> + output->initialPanningMode = XF86CrtcPanningModeBorderPush;
You should consider printing a warning or even error if the mode is wrong.
Other modes might be added in the future.
> + * panningMode: e.g. push against border or proportional to pointer
> position.
> + * Added in ABI version ???
Please change XF86_CRTC_VERSION if you change the struct.
Also only add entries to the end of the struct. This might look ugly,
but is backward compatible. Otherwise we would have to change the server
ABI for just that.
> @@ -605,6 +614,7 @@ struct _xf86Output {
> BoxRec initialTotalArea;
> BoxRec initialTrackingArea;
> INT16 initialBorder[4];
> +xf86CrtcPanningMode initialPanningMode;
Similar, change XF86_OUTPUT_VERSION.
> + propx = crtc->panningBorder[0] +
> +(((x - crtc->panningTotalArea.x1) *
> + (width - crtc->panningBorder[0] -
> crtc->panningBorder[2])) /
> + (crtc->panningTotalArea.x2 -
> crtc->panningTotalArea.x1));
This *looks* like it could require some rounding - but I could be
totally wrong.
Thanks
Matthias
--
Matthias Hopf ____ __
Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ m...@mshopf.de
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: proportional panning
On Jun 08, 09 17:55:20 +0200, Xavier Bestel wrote: > Why not making the proportional mode simply replace the push mode ? > Why keeping an allegedly inferior panning mode ? Don't. Some people are used to this behavior. Matthias -- Matthias Hopf ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ m...@mshopf.de 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: proportional panning
On May 23, 09 19:24:31 +0100, David De La Harpe Golden wrote: > But it's "border-push" type panning. That means to scroll new sections > of the display into view you "push" against the border. Back in the > day, some amiga stuff instead used "proportional" panning to move the > viewport about the screen. Why would you want this? "Pushing" against > a border means you need to push beyond where you want to click on to > bring whatever it is fully on-screen, then move back. With the > proportional way, every viewport pointer position corresponds to a > particular point on the panning area. It allows rapid scrolling about > large panning areas, at cost of some precision. Yes, you're right - I forgot how it was on the Amiga. Shame on me. You're more than welcome to add this to the panning code. Matthias -- Matthias Hopf ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ m...@mshopf.de 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: Setting resolution of external monitor
On May 20, 09 11:49:30 +0200, Éric Piel wrote: > Op 20-05-09 09:06, Oliver Block schreef: > > The laptop display has a native resolution of 1680x1050. The external > > screen as a (maximal) resolution of 1920x1080. > > Can someone explain me why I cannot select 1920x1080 as a resolution? > > Any hints what to do? > From what I understand you want "panning". I would do it with this command: > xrandr --output PANEL --mode 1680x1050 --panning 1920x1080 Not necessarily. Panning is certainly helpful, but the driver doesn't even detect the higher resolution. Given you have a dead old version of radeonhd, please try the current 1.2.5 one. It is also probably that you stumble over an randr bug in the Xserver, as 1.4.2 is also ancient. To get more informative output in the log also try starting X with -logverbose 7. If the newer versions don't help, try posting on the radeonhd mailing list - see http://www.x.org/wiki/radeonhd Matthias -- Matthias Hopf ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ m...@mshopf.de 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: Mobility radeon 3470 problem with radeonhd driver
On Apr 11, 09 06:59:29 +0200, Kálmán "KAMI" Szalai wrote: > I got such warning in xorg log: > (WW) RADEONHD(0): M82: HW 2D acceleration is not implemented yet. Your hardware has a r6xx derived chip, and you need a newer drm for it to work. And you need version 1.2.5, 1.2.4 didn't have 2D acceleration for r6xx included. Also, there is no 3D driver for your card yet. Best read http://www.x.org/wiki/radeonhd Matthias -- Matthias Hopf ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ m...@mshopf.de Phone +49-911-74053-715 __) |_| __) |__ R & D www.mshopf.de ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[ANNOUNCE] xf86-video-radeonhd 1.2.5 Release
Announcing the 1.2.5 Release of the xf86-video-radeonhd driver. RadeonHD is the X.org X11 driver for AMD GPG (ATI) r5xx/r6xx/r7xx chipsets. The development is driven by Novell and AMD at the time of writing, together with a community of open source developers around this driver. AMD provides free documentation for the chipsets. Note the wiki on http://wiki.x.org/wiki/radeonhd Version 1.2.5 improvements: - Added 2D acceleration for R6xx and R7xx. - Added XVideo support for R6xx and R7xx. - Added support for RS880 and RV790. - Added RandR 1.3 mandatory properties. - Refactoring of MC code. - Enable DRI support by default on R5xx and RS6xx. - LUT (color lookup table) fixes. - Tons of quirk table entries and bug fixes. - Fix register accesses for processors that reorder memory writes. http://xorg.freedesktop.org/releases/individual/driver/xf86-video-radeonhd-1.2.5.tar.gz MD5: 0d024ace7aac324f79a9f516aaba68a0 xf86-video-radeonhd-1.2.5.tar.gz SHA1: 5bc97e7b9ed24669466c6bdebcf7062cd790c8f3 xf86-video-radeonhd-1.2.5.tar.gz http://xorg.freedesktop.org/releases/individual/driver/xf86-video-radeonhd-1.2.5.tar.bz2 MD5: 10669b08101cb6d69894cc44b47e5094 xf86-video-radeonhd-1.2.5.tar.bz2 SHA1: 64fc0eb5209adba5479396bafe53b50ded6c0940 xf86-video-radeonhd-1.2.5.tar.bz2 Matthias -- Matthias Hopf ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ m...@mshopf.de Phone +49-911-74053-715 __) |_| __) |__ R & D www.mshopf.de pgp4cmdMpDNVQ.pgp Description: PGP signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xinerama is broken in xorg-server 1.5.3
On Mar 11, 09 11:33:44 -0300, Claudinei Matos wrote: > Is there anybody else having problem with xinerama and/or switching > between multiple video cards? I think it's not working reasonably for quite some time now. Nobody cared so far (code-wise). Matthias -- Matthias Hopf ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ m...@mshopf.de 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: Set property in RandR
On Mar 11, 09 11:31:55 +0800, gordony...@viatech.com.cn wrote: > RandR support output property. But I want to know whether > xf86CrtcSetMode() is called if I set the output property. To the best of my knowledge it isn't, and I would wonder why that should ever be the case. A driver might change the mode itself, though, if it wishes, and it is notified on property changes, so a *driver* can do that. There might be use cases, but for the moment I fail to see any. Matthias -- Matthias Hopf ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ m...@mshopf.de 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: Radeon: randr 1.3 panning possible?
On Mar 09, 09 19:38:05 +0100, Krzysztof Halasa wrote: > Not sure, perhaps some wrong settings in xorg.conf? Nothing apparent > there. > Hmm, do I need DRI for acceleration? Yes, and the r6xx-r7xx-support branch, specifically. Matthias -- Matthias Hopf ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ m...@mshopf.de 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: Radeon: randr 1.3 panning possible?
On Mar 09, 09 16:54:32 +0100, Krzysztof Halasa wrote: > Yes, EXA. It's R600+ and my impression was it's not yet accelerated at > all. In fact, I only tried: > xorg-x11-drv-radeonhd-1.2.4-2.4.20090306git.fc10.x86_64. Exa support for R6xx has only been merged to master recently. And there hasn't been a release of that yet. CU Matthias -- Matthias Hopf ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ m...@mshopf.de 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: Radeon: randr 1.3 panning possible?
On Mar 08, 09 22:52:13 +0100, Krzysztof Halasa wrote: > Panning works with radeonhd. Unfortunately, the driver is too slow to be > usable. Why is that? Have you tried using Option "AccelMethod" "shadowfb" or "exa" ? CU Matthias -- Matthias Hopf ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ m...@mshopf.de Phone +49-911-74053-715 __) |_| __) |__ R & D www.mshopf.de ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[ANNOUNCE] libXrandr 1.3.0
Final RandR 1.3 release of libXrandr. Changes to libXrandr-1.2.99.4: Alan Coopersmith (1): Add README with pointers to mailing list, bugzilla & git repos Julien Cristau (1): Fix thinkos Keith Packard (1): Send X_RRGetOutputPrimary when making an X_RRGetOutputPrimary request Matthias Hopf (1): Bump to 1.3.0 Paulo Cesar Pereira de Andrade (1): Janitor: make distcheck, compiler warnings, .gitignore All changes to libXrandr-1.2.3: Adam Jackson (9): Remove RCS tags. Add GetScreenResourcesCurrent Add [GS]etOutputPrimary Use RRSimpleCheckExtension in functions returning void Fix type of GetReq() argument. Use RRCheckExtension in function returning a value. Be sure to return NULL when returning no properties. Define _XRRHasRates internally. libXrandr 1.2.99.4 Alan Coopersmith (1): Add README with pointers to mailing list, bugzilla & git repos Julien Cristau (5): Set attr->pendingNparams in XRRGetCrtcTransform() Merge branch 'transform-proposal' of git.freedesktop.org:/git/xorg/lib/libXrandr RRNotify subevents have 'window' at different offsets, the sequel Bump to 1.2.91 Fix thinkos Keith Packard (5): Add support for new Transform requests. Support CRTC Transform filters Eliminate inverse matrix from randr transform protocol Set NparamsFilter in XRRGetCrtcTransform return value. Send X_RRGetOutputPrimary when making an X_RRGetOutputPrimary request Matthias Hopf (5): Panning support Nuke config-timestamp for panning. Bump to 1.2.99.2. Bump to 1.2.99.3 Bump to 1.3.0 Paulo Cesar Pereira de Andrade (1): Janitor: make distcheck, compiler warnings, .gitignore Tomas Carnecky (1): RRNotify subevents have 'window' at different offsets. http://xorg.freedesktop.org/archive/individual/lib/libXrandr-1.3.0.tar.bz2 MD5: 68eb59c3b7524db6ffd78746ee893d1d libXrandr-1.3.0.tar.bz2 SHA1: 33dd2f67060465f872db9ea03f597e28517f0c8e libXrandr-1.3.0.tar.bz2 http://xorg.freedesktop.org/archive/individual/lib/libXrandr-1.3.0.tar.gz SHA1: ab410ec41be47652bd919446806b68311f1a38da libXrandr-1.3.0.tar.gz MD5: 2ad5e56b03ea3a647778172dccb4e6b9 libXrandr-1.3.0.tar.gz Matthias -- Matthias Hopf ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ m...@mshopf.de Phone +49-911-74053-715 __) |_| __) |__ R & D www.mshopf.de pgphL6ysdHsiO.pgp Description: PGP signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[ANNOUNCE] randrproto 1.3.0
Final RandR 1.3 release of randrproto. Unchanged with respect to 1.2.99.4. Changes since randrproto 1.2.2: Adam Jackson (7): Add GetScreenResourcesCurrent Fix RRNumberRequests GSRC added in 1.3, not 1.2 More doc for CRTC transforms Indent CRTC transform docs to match the rest of the requests. Add [GS]etOutputPrimary Zero reply from GetPanning means panning not supported. Julien Cristau (1): spec: add missing list of clones to RRGetOutputInfo reply Keith Packard (8): Add Transform request proposal for 1.3 Add filters to CRTC transforms. Eliminate inverse matrix from randr transform protocol Describe projective transform additions in Introduction Merge branch 'transform-proposal' Update to version 1.2.99.1 Remove duplicate GetScreenResourcesCurrent declarations Merge commit 'origin/master' Maarten Maathuis (1): Fix typo in 83f3f29dd3ac5d3875b5edef5805d6adb6a02698. Matthias Hopf (14): Panning protocol extension Panning protocol description Panning protocol bits description Add panning to versioning information. Nuke config-timestamp for panning. Specifying panning update on screen size change. Bump to 1.2.99.2 Add unicode art pictures for panning. Panning tracking areas describe full screen if set to 0. Bump to 1.2.99.3 Add description of standard properties. Should read "EDID", not "EdidData". Add standard property name defines. Bump to 1.2.99.4 Bump to 1.3.0 Paulo Cesar Pereira de Andrade (1): Janitor: Correct make distcheck and dont distribute autogen.sh http://xorg.freedesktop.org/archive/individual/proto/randrproto-1.3.0.tar.bz2 MD5: a49416013fff33c853efb32f1926551e randrproto-1.3.0.tar.bz2 SHA1: 442de2a6a2145e49f9ef12cadbea69140f9ca066 randrproto-1.3.0.tar.bz2 http://xorg.freedesktop.org/archive/individual/proto/randrproto-1.3.0.tar.gz MD5: 5804ffeea0e40982258cc4618b8c6f07 randrproto-1.3.0.tar.gz SHA1: cc0bd43813bf17b07f5aae17d18cc1f9001049ad randrproto-1.3.0.tar.gz Matthias -- Matthias Hopf ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ m...@mshopf.de Phone +49-911-74053-715 __) |_| __) |__ R & D www.mshopf.de pgpQ45P9VKvwf.pgp Description: PGP signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Keyboard events and console switching
On Jan 23, 09 10:27:12 +1100, Daniel Stone wrote: > On Thu, Jan 22, 2009 at 05:36:52PM +0100, Matthias Hopf wrote: > > On Jan 22, 09 16:55:08 +0100, Helge Bahmann wrote: > > > Things get even more unfriendly if console switching is initiated by chvt > > > from > > > a background service (don't ask). I propose to change the current logic > > > for > > > releasing keys on VT switch -- release them before switching away from > > > the > > > server, instead of after switching back. Would a patch like the attached > > > one > > > be acceptable? I finally got around to verify this patch against our bugs. Unfortunately, no change in behavior. I had to backport the patch, though, and it wasn't exactly trivial, so there might have been errors. > > We have several bugs open for openSUSE because of this behavior - so I'm > > all for a change. I don't know the inner workings of this area in X, so > > I can't claim to understand the patch completely, but I will give it a > > try. So if it works, I really suggest taking it. > > It should already work: please file a bug and assign it to me, and I'll > take care of it ASAP. I requested a bug to be opened upstream - I will ping you when this has been done. Thanks in advance, Daniel! Matthias -- Matthias Hopf ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ m...@mshopf.de 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: randrproto version in 1.6
On Feb 18, 09 21:09:54 -0800, Keith Packard wrote: > On Wed, 2009-02-18 at 18:11 -0800, Jeremy Huddleston wrote: > > Is randrproto going to be stabilized before 1.6 is pushed out? It > > seems odd to have the final 1.6 server depend on an rc of the protocol > > headers. It seems obvious to me, but I wanted to throw it out there > > to make sure it doesn't get missed. > > Yeah, 'someone' should do a randrproto release... I just did 1.2.99.4. A final 1.3 release is pending from my side - I don't have anything to add ATM. Same goes for libXrandr. Matthias -- Matthias Hopf ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ m...@mshopf.de Phone +49-911-74053-715 __) |_| __) |__ R & D www.mshopf.de ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[ANNOUNCE] randrproto 1.2.99.4
Hopefully the last before (maybe equivalent except version number) before 1.3... Changes since 1.2.99.3: Adam Jackson (1): Zero reply from GetPanning means panning not supported. Maarten Maathuis (1): Fix typo in 83f3f29dd3ac5d3875b5edef5805d6adb6a02698. Matthias Hopf (4): Add description of standard properties. Should read "EDID", not "EdidData". Add standard property name defines. Bump to 1.2.99.4 Paulo Cesar Pereira de Andrade (1): Janitor: Correct make distcheck and dont distribute autogen.sh http://xorg.freedesktop.org/releases/individual/proto/randrproto-1.2.99.4.tar.gz MD5: 0ae9c23ae438d47ac4ad9d2c71066c9e randrproto-1.2.99.4.tar.gz SHA1: c095f1c7680bfafd99ed1c58f76fe33f234e556f randrproto-1.2.99.4.tar.gz http://xorg.freedesktop.org/releases/individual/proto/randrproto-1.2.99.4.tar.bz2 MD5: dba22f3a3791db31befec7a227c445a3 randrproto-1.2.99.4.tar.bz2 SHA1: 5266dac65661a58dcca999633d87a4d6708775a8 randrproto-1.2.99.4.tar.bz2 Matthias -- Matthias Hopf ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ m...@mshopf.de Phone +49-911-74053-715 __) |_| __) |__ R & D www.mshopf.de pgpTRnp5SSiA3.pgp Description: PGP signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: very slow performance of glxgears (68 fps)
On Feb 18, 09 12:58:49 -0500, Jim Gettys wrote: > On Wed, 2009-02-18 at 10:49 -0700, McDonald, Michael-p7438c wrote: > > Dumb question: Do LCD/Plasma/OLED/... Actually have vertical retrace? > > Does the vblank interval approach 0? > > LCD: yes > Plasma: yes > OLED: ? (still mostly vaporware, and I'm sure compatibility > means it > would have this characteristic at the moment, even if the technology > doesn't). You will always have the vertical retrace of the signal lane (read: TMDS, LVDS, or VGA). Unless you have a massively parallel RAM readout and connection to the display ;-) CU Matthias -- Matthias Hopf ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ m...@mshopf.de 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: very slow performance of glxgears (68 fps)
On Feb 18, 09 14:40:34 +, John Tapsell wrote: > > So it is a validation tool, but not a benchmark. > > > > A benchmark - by definition - gives you performance figures that can be > > compared with other systems, which gives you a reasonable notion of > > which of the systems is better. > > Right. If one system gets 100fps and another gets 1,000fps, then you > compare the two systems and say that one is better than the other. Which is not necessarily true with glxgears. And that is exactly all I'm saying. Anyway, apparently you don't want to understand that everybody actually developing on 3D here is sick of hearing glxgears "performance" numbers. Sorry for the rant Matthias -- Matthias Hopf ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ m...@mshopf.de 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: very slow performance of glxgears (68 fps)
On Feb 06, 09 01:56:19 +, John Tapsell wrote: > >> > glxgears is not a benchmark. > > At openSUSE we print out a warning now (well, this change went into > > *after* 11.1, unfortunately), that this is not a benchmark. We got really > > tired of these statements. > Except that it _is_ a benchmark. Or rather waas before the change. No, it never was. > If for example, without vsync, a user gets just 100fps on their new > nvidia card, then that is clearly showing that something is wrong. So it is a validation tool, but not a benchmark. A benchmark - by definition - gives you performance figures that can be compared with other systems, which gives you a reasonable notion of which of the systems is better. Which exactly is not the case with glxgears. Matthias -- Matthias Hopf ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ m...@mshopf.de 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: [ANNOUNCE] xf86-input-synaptics 1.0.0
On Feb 06, 09 07:02:22 -0500, James Cloos wrote: > Occasionally it is necessary to call 'git pull -t' to get all of the > tags into one's local clone. This is never necessary with tag objects. That's why they should be used. Matthias -- Matthias Hopf ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ m...@mshopf.de 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: [ANNOUNCE] xf86-input-synaptics 1.0.0
On Feb 02, 09 10:07:16 +1000, Peter Hutterer wrote: > Finally, we decided to go for a 1.0 release since 0.99.3 has been slumbering > for too long. > > Notable improvements since the 0.15.2 release: git has still 0.15.2 in configure.ac. And there is no tag. At least no tag object. git tag -a xf86-input-synaptics-1.0.0 Also I cannot configure the wheel emulation any more, which worked before on this laptop. Is there a known issue, or where can I look at? Matthias -- Matthias Hopf ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ m...@mshopf.de 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: very slow performance of glxgears (68 fps)
On Jan 30, 09 18:11:57 -0800, Bryce Harrington wrote: > On Fri, Jan 30, 2009 at 01:29:49PM -0800, Eric Anholt wrote: > > > $ glxgears > > > Failed to initialize TTM buffer manager. Falling back to classic. > > > 300 frames in 5.0 seconds = 59.884 FPS > > > 299 frames in 5.0 seconds = 59.621 FPS > > > 300 frames in 5.0 seconds = 59.818 FPS > > > > glxgears is not a benchmark. > > > > We sync to vblank because running glxgears at 1000fps is dumb. > > I am going to go out on a limb and guess we're going to see a crapload > of reports of "performance regression" due to reduced glxgears frame > rates. At openSUSE we print out a warning now (well, this change went into *after* 11.1, unfortunately), that this is not a benchmark. We got really tired of these statements. Matthias -- Matthias Hopf ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ m...@mshopf.de 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: Keyboard events and console switching
On Jan 23, 09 10:27:12 +1100, Daniel Stone wrote: > On Thu, Jan 22, 2009 at 05:36:52PM +0100, Matthias Hopf wrote: > > On Jan 22, 09 16:55:08 +0100, Helge Bahmann wrote: > > > Things get even more unfriendly if console switching is initiated by chvt > > > from > > > a background service (don't ask). I propose to change the current logic > > > for > > > releasing keys on VT switch -- release them before switching away from > > > the > > > server, instead of after switching back. Would a patch like the attached > > > one > > > be acceptable? > > > > We have several bugs open for openSUSE because of this behavior - so I'm > > all for a change. I don't know the inner workings of this area in X, so > > I can't claim to understand the patch completely, but I will give it a > > try. So if it works, I really suggest taking it. > > It should already work: please file a bug and assign it to me, and I'll > take care of it ASAP. The issue is that we were never able to reproduce these bugs here at SuSE - but for some people they find the same behavior for a long time already. It's also possible that this only surfaces with the openSUSE X.org server - you never know... I'll verify and get back to you. Thanks Matthias -- Matthias Hopf ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ m...@mshopf.de 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: Keyboard events and console switching
On Jan 22, 09 16:55:08 +0100, Helge Bahmann wrote: > Things get even more unfriendly if console switching is initiated by chvt > from > a background service (don't ask). I propose to change the current logic for > releasing keys on VT switch -- release them before switching away from the > server, instead of after switching back. Would a patch like the attached one > be acceptable? We have several bugs open for openSUSE because of this behavior - so I'm all for a change. I don't know the inner workings of this area in X, so I can't claim to understand the patch completely, but I will give it a try. So if it works, I really suggest taking it. Thanks a lot Matthias -- Matthias Hopf ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ m...@mshopf.de 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: Patch to xmodmap to allow disabling mouse buttons
On Jan 20, 09 17:01:26 +, Ben North wrote: > % xmodmap -e 'pointer = 1 0 0 4 5' > xmodmap: commandline:0: bad value 0 given for buttons list > xmodmap: 1 error encountered, aborting. > > On looking at the source, it seems that this is a misbehaviour of > 'parse_number' in handle.c, which rejects the string "0 ", i.e., a zero Good catch. Committed and pushed. The patch as you sent it didn't apply, though. Next time please use git format-patch. Matthias -- Matthias Hopf ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ m...@mshopf.de 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: [PATCH] xrandr: Simplify transform and scale code
On Jan 15, 09 11:52:53 +0100, Éric Piel wrote: > While reading the code of xrandr, I noticed some little possible > optimizations. Here they are :-) I consider them good code. Unnecessary, but reasonable initialization duplications. Matthias -- Matthias Hopf ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ m...@mshopf.de 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: [PATCH] xrandr: document transform and scale in the manpage
On Jan 15, 09 11:50:02 +0100, Éric Piel wrote: > Hello, > I was missing the documentation for the scale and transformation options > of xrandr. So I tried to write it. I played a bit with them, had a look > at the code, did some additionaly guesswork, and hopefully the description > should not be too far from the truth ;-) Thanks, applied. I think transformations are using homogeneous coordinates, but I might be wrong. Your description reads as if they do. That could require some rephrasing, upto then it's good as it is. Next time by 'git format-patch', please, it's easier to handle. CU Matthias -- Matthias Hopf ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ m...@mshopf.de 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: Current support and roadmap for discrete graphics card hot switching
On Jan 15, 09 16:20:32 +, Albert Vilella wrote: > leaving Nvidia and the downstream problems aside, how difficult would it be > to convince ATI/AMD to provide such kind of documentation? > Anyone insider here that can answer? In the current (approximate) list of - 3D documentation (huge) - General(!) Powermanagement support - r8xx Documentation (which will be out then) - Enhanced 3D documentation (even larger) - Displayport support this comes probably last. Add a year per line, and you'll get your docs in about 5 years time. Pessimistic from the time it takes point of view, optimistic from the "we can get the information" point of view. Matthias -- Matthias Hopf ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ m...@mshopf.de 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: Should RRGetCrtcInfo return panning bounds?
On Jan 09, 09 11:38:48 -0800, Keith Packard wrote: > On Fri, 2009-01-09 at 10:59 -0800, Andy Ritger wrote: > > Probably both the physical region currently scanned out by the CRTC, > > as well as the panning region, are useful things for an RandR client > > to query. I'm not sure how best to make both pieces of information > > available. > > I'm thinking that if we ever send the physical region scanned by the > CRTC, we should provide events that update it when panning occurs. Isn't already a RRCrtcChangeNotify sent? I never verified that myself, but I think in the context I thought I wanted them to be sent. > Given that the usage model for panning requires that applications be > allowed to fill the panning region, I'd say we should report that > rectangle in the CrtcInfo (and Xinerama too). If the user wants a > presentation that fills a monitor, they should set the panning region to > match the monitor anyway. Hm. Sounds logical. Still, the currently presented CRTC should be queryable. CU Matthias -- Matthias Hopf ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ m...@mshopf.de 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: Should RRGetCrtcInfo return panning bounds?
On Jan 12, 09 18:12:41 +0100, Kai-Uwe Behrmann wrote: > If crtc does not provide the physical monitor arrangement, where shall the > x and y else come from? The Xinerama API comes to mind, but is this planed > to persist or already deprecated in favour of XRandR? This would be the top left edge of the panning region for this CRTC in Keith's scheme. Matthias -- Matthias Hopf ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ m...@mshopf.de 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: Should RRGetCrtcInfo return panning bounds?
On Jan 09, 09 10:39:07 -0800, Keith Packard wrote: > RRGetCrtcInfo currently returns the x/y/width/height of the current CRTC > view, and not the panning region. This seems wrong to me -- the panning > region is the logical area displayed by the CRTC. Hm. I don't know. It's just not defined yet. I think there is no other place to get the actually visible CRTC view from, and I don't know what is better suited for RandR 1.2 applications to behave nicely. Width and height can be trivially fetched from the mode, but I think that's not true for the position. If we were to change semantics here, we should add that to RRGetPanning (given that the "standard" is not standardized yet, we can change it), so we would have to add another two CARD16 values for current x and y. Also, this would probably influence xrandr quite a bit. Matthias -- Matthias Hopf ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ m...@mshopf.de 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: [radeonhd] Initial Radeon R6xx/R7xx acceleration support pushed
On Dec 30, 08 22:12:24 -0500, Alex Deucher wrote: > > I'm a dev by trade and I'd be quite happy to test it on my system (R770) and > > provide reports, or would you only recommend this for people who actually > > want to hack on it? > > It's not particularly useful for end users at the moment. Alex's right - at this particular point nothing of this code is particularly useful for users. OTOH, if you love experimenting, testing r600_demo could be useful. RV770 works fine here, so in case anybody finds that it doesn't work for his/her card, a report would be welcome. Also, so far nobody verified on notebook chipsets (RS780 is the only one, AFAIK) - but you would need to hack r600_demo.c a bit with the PCI IDs at least. Matthias -- Matthias Hopf ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ m...@mshopf.de 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: xrandr: needs changes for dualhead + panning
On Dec 19, 08 20:50:29 +0100, Maarten Maathuis wrote: > On 12/19/2008 08:42 PM, Carl Karsten wrote: >> Maarten Maathuis wrote: >>> The placement logic is output driven, and doesn't take panning into >>> account. So you end up with strange overlap. If dual head + panning was a >>> goal you might consider fixing this. It doesn't seem trivial to do from a >>> quick look. On the plus side it's just a xrandr change. You're right, forgot about that. Have to think about it. It's not really complicated, but you have to think about how to specify the type of panning as in: >> dual head + panning could mean >> >> a the whole space pans when you get to the side of the virtual space, >> b pan each physical display separately, >> c a combination of a/b. Good point. > (a) would need changes on the protocol side (imo) Probably not on the protocol side, but maybe in the xserver implementation. OTOH it might already be possible to specify this with borders. Again, have to think about it :^) > I was thinking of (b). CU Matthias -- Matthias Hopf ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ m...@mshopf.de 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: [RFC] RandR 1.3 properties, version 2
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 means that > the XRandR EDID_DATA atom now becomes what ? Just "EDID" Reason was that people objected to all caps properties, and EDIDData looked awkward to me (and EdidData would be plainly wrong, because EDID is an abbreviation). CU Matthias -- Matthias Hopf ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ m...@mshopf.de 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: [PATCHES] improve gamma support for randr-1.2 drivers
On Dec 18, 08 16:07:09 +0100, Maarten Maathuis wrote: > On 12/18/2008 02:50 PM, Matthias Hopf wrote: > > On Dec 17, 08 21:38:50 +0100, Maarten Maathuis wrote: > > > >>> Will do, as part of some more fixes. Anything else than happens to be > >>> on your mind while I'm breaking abi? > >>> > > > > Nope, not from my side. Is this supposed to get into 1.6 still, or just > > in master? > > I'm unsure, it's more than a little bug fix, what would you do? Keith is the release manager, he will have the last word. CC'ing him. It probably depends on how stable you think your current work is. Matthias -- Matthias Hopf ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ m...@mshopf.de 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: [RFC] RandR 1.3 properties, version 2
On Dec 16, 08 18:17:03 +0100, Matthias Hopf wrote: > 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 property has changed. I'll add it to the Server16Branch page. 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. For SignalProperties, CompatibilityList, and CloneList (all not yet implemented in radeonhd either), a fix to xrandr was necessary, as it didn't print out INT/32 or Atom arrays. Matthias -- Matthias Hopf ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ m...@mshopf.de 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: [PATCHES] improve gamma support for randr-1.2 drivers
On Dec 17, 08 21:38:50 +0100, Maarten Maathuis wrote: > > Will do, as part of some more fixes. Anything else than happens to be > > on your mind while I'm breaking abi? Nope, not from my side. Is this supposed to get into 1.6 still, or just in master? Matthias -- Matthias Hopf ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ m...@mshopf.de 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: [RFC] RandR 1.3 properties, version 2
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 string check > to my display color profile management code, but is there a > reason to change it ? It conforms to the standard naming scheme we AFAIU agreed on on the mailing list. I'd have no issues with adding a non-advocated EDID_DATA again to the server, if that sounds fit reasonable. Keith? Matthias -- Matthias Hopf ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ m...@mshopf.de 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: [PATCHES] improve gamma support for randr-1.2 drivers
On Dec 17, 08 16:43:00 +0100, Maarten Maathuis wrote: > > My main question is, are there any xserver ABI's to bump due to the > > changes to the xf86CrtcRec struct? > > Answering myself, no ABI bump is needed, because i only appended > something to a structure, and multiple instances of that structure are > not allocated as one chunk of memory. I suggest bumping XF86_CRTC_VERSION, so that drivers can validate crtc->version before using the new fields (if they want to, that is). Matthias -- Matthias Hopf ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ m...@mshopf.de 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: proto/randrproto: Branch 'master'
On Dec 16, 08 22:34:22 +0200, Fatih Aşıcı wrote: > Salı 16 Aralık 2008 tarihinde, Matthias Hopf şunları yazmıştı: > > +#define RR_PROPERTY_SIGNAL_FORMAT "SignalFormat" > > +#define RR_PROPERTY_SIGNAL_FORMAT "SignalProperties" > > It looks like a copy/paste error? F*ck. Thanks. Apparently already fixed by Maarten. Matthias -- Matthias Hopf ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ m...@mshopf.de 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: xrandr --panning usage
On Dec 16, 08 13:13:22 -0500, Felix Miata wrote: > > Just to mention it: done in the 1.2.99.3 release of xrandr. > > Static config in Xserver is done as well. > > Will builds of those be available in opensuse.org/repositories/*/*/11.1? Panning will only be available in Xserver 1.6. As 11.1 is already out, and Xserver 1.6 isn't yet, we won't have it in 11.1. There will probably be some repro for Xserver 1.6, which will then include newer apps (including xrandr), but not unless it's actually released upstream. Which it isn't yet. Matthias -- Matthias Hopf ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ m...@mshopf.de 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: xrandr --panning usage
On Dec 10, 08 12:05:04 +0100, Matthias Hopf wrote: > On Dec 10, 08 00:05:12 -0800, Keith Packard wrote: > > It seems to me that the size of the panning area for each crtc should be > > used in the computation of screen size. This would make > > > > $ xrandr --output LVDS --panning 2048x900 > > > > "just work", resizing the screen to 2048x900 and setting the panning > > area. The current code requires that the user set the frame buffer size > > along with the panning area. > > Yes, that is one of the things that has to be implemented. Static > panning configuration is more important at first, because that should > get into Xserver 1.6 still. Just to mention it: done in the 1.2.99.3 release of xrandr. Static config in Xserver is done as well. Matthias -- Matthias Hopf ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ m...@mshopf.de 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: Accounts and membership?
On Dec 16, 08 14:12:38 +0100, Matthias Hopf wrote: > > who (or which group) is currently doing membership and account requests? > > I wanted my student from VoC 2007 have its project published on git.fdo, > > but his request for an account sits uncommented there since September: > Any updates on that? > Even if it is that there are no updates?!? Thanks, Daniel, Ajax, for tackling that. Matthias -- Matthias Hopf ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ m...@mshopf.de 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: [RFC] RandR 1.3 properties, version 2
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 property has changed. I'll add it to the Server16Branch page. 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. Matthias -- Matthias Hopf ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ m...@mshopf.de 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: Accounts and membership?
On Nov 13, 08 12:37:39 +0100, Matthias Hopf wrote: > Guys, > > who (or which group) is currently doing membership and account requests? > I wanted my student from VoC 2007 have its project published on git.fdo, > but his request for an account sits uncommented there since September: > > http://bugs.freedesktop.org/show_bug.cgi?id=17663 Any updates on that? Even if it is that there are no updates?!? Matthias -- Matthias Hopf ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ m...@mshopf.de Phone +49-911-74053-715 __) |_| __) |__ R & D www.mshopf.de ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[ANNOUNCE] xrandr 1.2.99.3 Release
Version 1.2.99.3 improvements over 1.2.3: - Panning support - Transformation support - Various fixes Git Shortlog: Adam Jackson (1): Accept --props synonym for --prop Alan Coopersmith (1): Man page typo fix Egbert Eich (1): Fix for 64bit: feed a pointer to the right size variable to scanf(). Eric Piel (1): update the manpage Hong Liu (1): Move outputs among crtcs as necessary. Fixes 14570 Julien Cristau (4): Manpage typo fixes Merge branch 'transform-proposal' of git.freedesktop.org:/git/xorg/app/xrandr Fix build outside of the source dir Require libXrandr 1.2.91 Keith Packard (15): Add output scaling using the 1.3 transform requests Manage transform filters. Use bilinear for non-identity scale. Transform mode bounds when computing sizes. Eliminate inverse matrix from randr transform protocol Add --transform to pass arbitrary transforms to the server Make screen undersize a warning instead of an error Add keystone.5c program to help compute transforms. Track toolkit name change (chrome->nichrome) Build and install xkeystone program from keystone.5c add --transform none to reset to identity Execute xrandr to set keystone correction Fix up xkeystone to use current screen/output settings Exit when select output is not available Check return value from XRRGetCrtcTransform Add --scale and --transform to --help output Matthias Hopf (8): Add panning support. Bump to 1.2.99.2, RandR requirements to 1.2.99.2 Add manpage entry. Only set transforms if actually changed. Panning tracking areas describe full screen if set to 0. Use it as default. Don't trash panning area, except if --panning or --fb is given. Add keystone.5c to EXTRA_DIST Bump to 1.2.99.3 Matthieu Herrb (1): Don't use GNU make only constructs. http://xorg.freedesktop.org/releases/individual/app/xrandr-1.2.99.3.tar.gz MD5: 50f0c7bfcd02a32f595d4cb81cdd5e5e xrandr-1.2.99.3.tar.gz SHA1: 555c0979ca199c6f127806895d10f2b9a8ee7287 xrandr-1.2.99.3.tar.gz http://xorg.freedesktop.org/releases/individual/app/xrandr-1.2.99.3.tar.bz2 MD5: f1a591364d915e6c924b373721a72b4a xrandr-1.2.99.3.tar.bz2 SHA1: bc5ee2b8e35b02ce04afdef7b513fec7442a64a1 xrandr-1.2.99.3.tar.bz2 Matthias -- Matthias Hopf ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ m...@mshopf.de Phone +49-911-74053-715 __) |_| __) |__ R & D www.mshopf.de pgpYqMhE4v64c.pgp Description: PGP signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [ANNOUNCE] radeonhd 1.2.4 Release
On Dec 12, 08 18:52:55 +0100, Luca Tettamanti wrote: > On Fri, Dec 12, 2008 at 5:53 PM, Gene Heskett > wrote: > > On Friday 12 December 2008, Matthias Hopf wrote: > >>Announcing the 1.2.4 of the xf86-video-radeonhd driver. > >> > > I still don't have drm, so glxgears is only marginally faster (850 fps vs > > 800) > > than before on an RV610 (Diamond HD2400-Pro), and things like tvtime still > > cannot run. > > Still no DRM nor XV (which would use DRM anyway I believe) on R600 and newer. And that's not even related to the X11 driver. As soon as we have a R6xx DRI module for Mesa, it will probably "just work" (TM) with the current X11 driver. Fingers crossed, that is. XV will happen in about the same timeframe. Again, fingers crossed. And, PLEASE, don't keep xorg-announce included in the mail recipients when replying to a announcement mail. Matthias -- Matthias Hopf ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ m...@mshopf.de Phone +49-911-74053-715 __) |_| __) |__ R & D www.mshopf.de ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[ANNOUNCE] radeonhd 1.2.4 Release
Announcing the 1.2.4 of the xf86-video-radeonhd driver. RadeonHD is the X.org X11 driver for AMD GPG (ATI) r5xx/r6xx chipsets. The development is driven by Novell at the time of writing, together with a community of open source developers around this driver. AMD provides free documentation for the chipsets. Note the wiki on http://wiki.x.org/wiki/radeonhd Version 1.2.4 improvements: - Added HDMI support. - Added support for RV710, RV730 (DCE 3.2). - Added screen rotation support. - Added RandR 1.3 panning support. - Many acceleration and build fixes. http://xorg.freedesktop.org/releases/individual/driver/xf86-video-radeonhd-1.2.4.tar.gz MD5: d2e72ffdc37f97cafba255e2a14f1fa9 xf86-video-radeonhd-1.2.4.tar.gz SHA1: 30b3f7f50a3ba7429dc88e5b93b9cd2e0d63fdfb xf86-video-radeonhd-1.2.4.tar.gz http://xorg.freedesktop.org/releases/individual/driver/xf86-video-radeonhd-1.2.4.tar.bz2 MD5: 3c9cfffe7e3d795dde59ea0eef7361b1 xf86-video-radeonhd-1.2.4.tar.bz2 SHA1: 1634e354c54a703910c0ae547fd27285e02afb28 xf86-video-radeonhd-1.2.4.tar.bz2 Matthias -- Matthias Hopf ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ m...@mshopf.de Phone +49-911-74053-715 __) |_| __) |__ R & D www.mshopf.de pgpL4vDTKmiLv.pgp Description: PGP signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[ANNOUNCE] libXrandr 1.2.99.3 Release
Version 1.2.99.3 improvements over 1.2.99.1: - Panning support - Output primary support Version 1.2.99.1 improvements over 1.2.3: - Transformation support - GetScreenResourcesCurrent support http://xorg.freedesktop.org/releases/individual/lib/libXrandr-1.2.99.3.tar.gz MD5: a7c375e8f914b86a6ce8adeeacefd397 libXrandr-1.2.99.3.tar.gz SHA1: 27335ebccd29ed48c9cac32618b8e6e57072baae libXrandr-1.2.99.3.tar.gz http://xorg.freedesktop.org/releases/individual/lib/libXrandr-1.2.99.3.tar.bz2 MD5: cd68c899190c282bb0d18110a985fdc8 libXrandr-1.2.99.3.tar.bz2 SHA1: 63f6837f5c05f8f0578309beb0e971fe86eda4ef libXrandr-1.2.99.3.tar.bz2 Matthias -- Matthias Hopf ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ m...@mshopf.de Phone +49-911-74053-715 __) |_| __) |__ R & D www.mshopf.de pgpbbvcrECAwT.pgp Description: PGP signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[ANNOUNCE] randrproto 1.2.99.3 Release
Version 1.2.99.3 improvements over 1.2.99.1: - Panning support - Output primary support Version 1.2.99.1 improvements over 1.2.2: - Transformation support - GetScreenResourcesCurrent support http://xorg.freedesktop.org/releases/individual/proto/randrproto-1.2.99.3.tar.gz MD5: bbf7f8d31aeeef7e559339c1376e4fa7 randrproto-1.2.99.3.tar.gz SHA1: 23c6803415335f2bf56ae85b38093ef66554ff39 randrproto-1.2.99.3.tar.gz http://xorg.freedesktop.org/releases/individual/proto/randrproto-1.2.99.3.tar.bz2 MD5: d4a7b90d826dfa1c39d41d323ce7366c randrproto-1.2.99.3.tar.bz2 SHA1: d99689a67d2dbbd67b4e7850b78c7e9a0f34c8d5 randrproto-1.2.99.3.tar.bz2 Matthias -- Matthias Hopf ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ m...@mshopf.de Phone +49-911-74053-715 __) |_| __) |__ R & D www.mshopf.de pgpsEwTLAnFxA.pgp Description: PGP signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xrandr --panning usage
On Dec 10, 08 08:27:20 -0800, Keith Packard wrote: > On Wed, 2008-12-10 at 12:05 +0100, Matthias Hopf wrote: > > Yes, that is one of the things that has to be implemented. Static > > panning configuration is more important at first, because that should > > get into Xserver 1.6 still. > > Can you get this done by next week? I'd like to close down new features > for 1.6 and start preparing for the release. Already working on it. Expect something today. 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: xrandr --panning usage
On Dec 10, 08 00:05:12 -0800, Keith Packard wrote: > It seems to me that the size of the panning area for each crtc should be > used in the computation of screen size. This would make > > $ xrandr --output LVDS --panning 2048x900 > > "just work", resizing the screen to 2048x900 and setting the panning > area. The current code requires that the user set the frame buffer size > along with the panning area. Yes, that is one of the things that has to be implemented. Static panning configuration is more important at first, because that should get into Xserver 1.6 still. 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: [PATCH 10/13] xserver: randr: Protocol bits for panning support
On Dec 04, 08 19:24:48 +0100, Julien Cristau wrote: > You're not updating SProcRandrVector, so the server will crash in > SProcRRDispatch if a swapped client calls one of the new requests, as > far as I can tell. You're absolutely right. Thanks for noticing! Fixed in git. 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: [PATCH 02/13] randrproto: Panning protocol description
On Dec 04, 08 09:29:24 -0800, Keith Packard wrote: > On Thu, 2008-12-04 at 12:31 +0100, Matthias Hopf wrote: > What happens with timestamps is that an application queries the system, > then something unrelated changes, then the application tries to set some > parameters. The result is that the settings fail and if the application > has no recovery mechanism (which is likely), the user is left confused. IMHO that points to broken applications. With xrandr that's acceptable, because xrandr is rather a showcase (and a power-user's tool) than a really user friendly display change application. > It's been a serious problem in the past, and the timestamps don't > eliminate inter-application races, they just narrow the window. I'm not exactly sure why they don't eliminate them. > The random failures caused by timestamps have been far worse than any > race conditions we've found. If any thing "important" changes, the > request will fail anyway, due to match errors or resources disappearing. The issue is that all requests still do timestamping, and when adding new functionality it should be consistent. If it's general consensus that timestamp checks should be removed, it should be done consistently as well. > > It turned out to be easier to understand, both in the spec and in code. > > Borders don't change if crtc dimensions change, while a separate box > > would. > > Sorry, I just now realized that this rectangle can't be 'absolute' in > the same way the other rectangles can -- it moves with the panning Exactly. That, and other potential issues. I think we're really missing some ASCII art here ;-) > I think using an offset rectangle would be less confusing than your > border regions, as there wouldn't be any ambiguity over whether positive > values were inside the crtc rectangle or outside. Having positive values > make the box smaller is counter-intuitive to me, but I wouldn't want the > 'normal' values to be negative. Understood. I thought about several possibilities, but the borders I came up with were the least confusing of all. For me, that is. > > I assume so. I guess they can be added later. Will do that, but will > > take some time. > > I think we just need a picture of the four boxes here (screen, crtc, > border and tracking) so we can see how they nest or not). Yes. 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: [PATCH 00/13] RandR 1.3 Panning support
On Dec 04, 08 12:41:46 +0100, Matthias Hopf wrote: > > I've bumped the randrproto version to 1.2.99.1; we'll move to 1.3.0 when > > we're finished pulling in changes. Bumping to 1.2.99.2, in order to reflect dependencies. 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: [PATCH 00/13] RandR 1.3 Panning support
On Nov 28, 08 11:17:33 -0800, Keith Packard wrote: > On Fri, 2008-11-28 at 18:46 +0100, Matthias Hopf wrote: > > This set of patches adds panning support to RandR. Maybe it needs some > > tweaking when Keith's transformation patches are applied. > > Transforms are on master and the 1.6 branch. I think there are some > minor modifications needed here to deal with back-transforming the > pointer position from screen space to crtc space. I don't have good > thoughts on how this should actually work though. You'll need to try it > out and see what's needed, I think. I'll leave that for now (lack of time). Maybe next week or so. Eventually we have to claim that panning and transformations don't play nicely together yet. > > The patches include version bumps to 1.3.0, dunno whether that should be > > delayed until being actually final, please comment. > > I've bumped the randrproto version to 1.2.99.1; we'll move to 1.3.0 when > we're finished pulling in changes. Ok. > > The current implementation behaves nicely on screen size changes and mode > > changes, but I'd like to have it verified more before removing the > > documentation parts that state that behavior on these actions is undefined. > > If you're reasonably happy with the current behaviour, please just write > that into the spec. If we need to change it, we'll change the spec and > the implementation. Ok. > > Also, there is no startup time support for about the same reason, as there > > is no per-crtc configuration in xorg.conf. > > We've got per-monitor configuration support, which is where the panning > would be added. The code currently shares CRTCs where monitor modes Thought so, but haven't done that yet. 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: [PATCH 09/13] xserver: randr: Panning support
On Nov 28, 08 11:11:22 -0800, Keith Packard wrote:
> On Fri, 2008-11-28 at 17:49 +0100, Matthias Hopf wrote:
>
> > +if (crtc->funcs->pan &&
> > + memcmp (mode, &saved_mode, sizeof(saved_mode)) == 0 &&
> > + saved_rotation == rotation) {
> > + crtc->funcs->pan (crtc, crtc->x, crtc->y);
> > + ret = TRUE;
> > + goto done;
> > +}
>
> I think this also need to check for transformation changes? And output
> property changes?
I haven't looked into transformation yet, but you're probably right.
I don't see ATM how output properties could influence panning.
> Should we call the low-level operation 'set_origin' instead of 'pan'?
No objections from my side.
> > +intpointerX;
> > +intpointerY;
>
> I'd prefer to not shadow the pointer position inside RandR; is there
> some way we can use the DIX pointer position here?
Actually, that was the one thing that was getting on my nerves as well.
But if *you* don't know a possibility, I certainly don't.
> We should also start to consider how MPX plays with panning.
Right. The shadowing should automatically take care of that it
*principally* works, but you might want to either disable panning by
some of the pointers, or specify that one has precedence over another,
or...
I don't think this should be done ad-hoc. We have to think about it.
> > +static Bool
> > +xf86RandR13SetPanning (ScreenPtr pScreen,
> > + RRCrtcPtr randr_crtc,
> > + BoxPtr totalArea,
> > + BoxPtr trackingArea,
> > + INT16 *border)
> > +{
> > +XF86RandRInfoPtr randrp = XF86RANDRINFO(pScreen);
> > +xf86CrtcPtrcrtc = randr_crtc->devPrivate;
> > +intret;
> > +
> > +if (crtc->version < 2)
> > + return FALSE;
> > +if (totalArea)
> > + memcpy (&crtc->panningTotalArea, totalArea, sizeof(BoxRec));
> > +if (trackingArea)
> > + memcpy (&crtc->panningTrackingArea, trackingArea, sizeof(BoxRec));
> > +if (border)
> > + memcpy (crtc->panningBorder, border, 4*sizeof(INT16));
> > +ret = xf86RandR13VerifyPanningArea (crtc, pScreen->width,
> > pScreen->height);
> > +xf86RandR13Pan (crtc, randrp->pointerX, randrp->pointerY);
>
> Probably need to verify before setting -- protocol requests should
> either succeed or fail without side effects. It looks to me like we
Right. Forgot about that so far.
> smash the old settings before checking the requested data. That would
> mean that VerifyPanningArea would take the three rectangles as separate
> arguments instead of pulling them from the crtc.
Actually, no. The way it's used in other places it should change the
crtc, I'm thinking more about saving and restoring the data.
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: [PATCH 02/13] randrproto: Panning protocol description
On Nov 28, 08 11:04:48 -0800, Keith Packard wrote: > > + Note that changes to the screen size might invalidate panning > > + parameters. In these cases panning might be silently disabled, or the > > + panning parameters are updated automatically as necessary. The exact > > + behavior of the implementation is undefined. If the panning parameters > > + do not conflict with new screen size, panning remains enabled > > + unchanged. > > I don't see a need to leave this undefined; let's specify what screen > size changes do to panning and then implement it. Or vice-versa. And, Ok. > > + If 'config-timestamp' does not match the current configuration > > + timestamp (as returned by RRGetScreenResources), 'status' is set to > > + InvalidConfigTime and the remaining reply data is empty. Otherwise, > > + 'status' is set to Success. > > just eliminate the config-timestamp stuff, it isn't useful now that we > have stable resource IDs etc. Note that the rest of the RandR protocol > doesn't look at config-timestamp anymore as it only causes trouble. Ok. > > + If 'timestamp' is less than the time when the configuration was last > > + successfully set, the request is ignored and InvalidTime returned in > > + status. > I'd say all of this timestamp stuff can be eliminated. I'm unsure - this just calls for races. > > + 'left', 'top', 'width', and 'height' contain the total panning area > > + for this CRTC. 'width' has to be larger than the CRTC's width, and > > + 'left'+'width' must be within the screen size, else a Match error > > + results. Equivalent restrictions for the height exist. The exception > > + is 'width' == 'height' == 0 which indicates that panning should be > > + disabled. > > I'd say that width >= crtc_width, the same for height. That way, you can It's actually implemented that way, the description is wrong. > You could make width == 0 mean to set width to the crtc_width (like > ClearArea does). Not setting, but using crtc_width. Setting would have different side effects (on mode changes to smaller modes, etc.) > > + 'track_left', 'track_top', 'track_width', and 'track_height' contain > > + the pointer area for which the panning region is updated. For normal > > + use cases it should enclose the panning area minus borders, and is > > + typically set to either the panning area minus borders, or to the > > + total screen size. If set to the total screen size, the CRTC will pan > > + in the remaining axis even if the pointer is outside the panning area > > + on a different CRTC. > > So, if the pointer is within this space, then the crtc is moved as far > as possible within the panning region to try and make the cursor > visible? Exactly. > > + 'border_left', 'border_top', 'border_right', and 'border_bottom' > > + define the distances from the CRTC borders that will activate panning > > + if the pointer hits them. If the borders are 0, the screen will pan > > + when the pointer hits the CRTC borders (behavior of pre-RandR Xserver > > + panning). If the borders are positive, the screen will pan when the > > + pointer gets close to the CRTC borders, if they are negative, the > > + screen will only pan when the pointer is already way past the CRTC > > + borders. Negative values might confuse users and are discouraged. > > + border_left + border_right has to be lower or equal than the CRTC's > > + width, else a Match error results. An equivalent restriction for the > > + height exists. > > Is there some reason to use borders instead of a separate rectangle > here? It turned out to be easier to understand, both in the spec and in code. Borders don't change if crtc dimensions change, while a separate box would. > Also, a couple of ascii-art pictures here would help a huge amount. I > had to read these several times to get any idea of what they all do, and > I'm still not sure I understand. I assume so. I guess they can be added later. Will do that, but will take some time. CU 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
[PATCH 00/13] RandR 1.3 Panning support
This set of patches adds panning support to RandR. Maybe it needs some tweaking when Keith's transformation patches are applied. The patches include version bumps to 1.3.0, dunno whether that should be delayed until being actually final, please comment. After applying the patches panning can be enabled e.g. by xrandr --output DVI --mode 1024x768 --fb 1600x1200 --panning 1600x1200 Please note that due to some stupidity in xrandr I haven't analyzed yet you always have to set the frame buffer size before panning. xrandr tries to reset the frame buffer size to the mode size by default. You can also specify the pointer area for which the screen should be panned (tracking area, useful for multi-monitor setups with partially panning displays), and borders that let the screen pan before you actually hit the physical borders, e.g. with xrandr --output DVI --fb 1600x1200 --panning 1600x1200+0+0/1600x1200+0+0/50/50/50/50 The current implementation behaves nicely on screen size changes and mode changes, but I'd like to have it verified more before removing the documentation parts that state that behavior on these actions is undefined. I'm not completely satisfied with the abstraction, as panning is a purely crtc related thing, but xrandr doesn't support setting crtc related properties yet. Thus the to-be-set panning information is analyzed per output, while it is actually set per crtc. Still, you probably won't notice with typical use cases. Also, there is no startup time support for about the same reason, as there is no per-crtc configuration in xorg.conf. Because the current RandR driver interface doesn't have support for panning, each time a mode_set() is called on the crtc. As this typically disrupts signal generation, a pan() call has been added for just updating the x/y crtc coordinates. See patch 13, which adds support for the radeonhd driver. Originally I planed to allow mode_set() with a NULL mode, but it's impossible to verify in the server whether the driver will support that or not, thus a separate call. 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
sorry...
... for the messed up sending order. Mailer error. 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
[PATCH 07/13] xserver: randr: Weird enough, crtc->version was never set upon creation. Fix that.
--- hw/xfree86/modes/xf86Crtc.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/hw/xfree86/modes/xf86Crtc.c b/hw/xfree86/modes/xf86Crtc.c index e9652e1..1c6eed0 100644 --- a/hw/xfree86/modes/xf86Crtc.c +++ b/hw/xfree86/modes/xf86Crtc.c @@ -96,6 +96,7 @@ xf86CrtcCreate (ScrnInfoPtr scrn, crtc = xcalloc (sizeof (xf86CrtcRec), 1); if (!crtc) return NULL; +crtc->version = XF86_CRTC_VERSION; crtc->scrn = scrn; crtc->funcs = funcs; #ifdef RANDR_12_INTERFACE -- 1.5.6 ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[PATCH 09/13] xserver: randr: Panning support
---
hw/xfree86/modes/xf86Crtc.c| 24 ++-
hw/xfree86/modes/xf86RandR12.c | 156
2 files changed, 178 insertions(+), 2 deletions(-)
diff --git a/hw/xfree86/modes/xf86Crtc.c b/hw/xfree86/modes/xf86Crtc.c
index 1c6eed0..566d703 100644
--- a/hw/xfree86/modes/xf86Crtc.c
+++ b/hw/xfree86/modes/xf86Crtc.c
@@ -315,8 +315,14 @@ xf86CrtcSetModeTransform (xf86CrtcPtr crtc, DisplayModePtr
mode, Rotation rotati
crtc->x, crtc->y);
}
-/* XXX short-circuit changes to base location only */
-
+if (crtc->funcs->pan &&
+ memcmp (mode, &saved_mode, sizeof(saved_mode)) == 0 &&
+ saved_rotation == rotation) {
+ crtc->funcs->pan (crtc, crtc->x, crtc->y);
+ ret = TRUE;
+ goto done;
+}
+
/* Pass our mode to the outputs and the CRTC to give them a chance to
* adjust it according to limitations or output properties, and also
* a chance to reject the mode entirely.
@@ -405,6 +411,20 @@ xf86CrtcSetMode (xf86CrtcPtr crtc, DisplayModePtr mode,
Rotation rotation,
return xf86CrtcSetModeTransform (crtc, mode, rotation, NULL, x, y);
}
+/**
+ * Pans the screen, does not change the mode
+ */
+_X_EXPORT void
+xf86CrtcPan (xf86CrtcPtr crtc, int x, int y)
+{
+crtc->x = x;
+crtc->y = y;
+if (crtc->funcs->pan)
+ crtc->funcs->pan (crtc, x, y);
+else
+ xf86CrtcSetMode (crtc, &crtc->mode, crtc->rotation, x, y);
+}
+
/*
* Output functions
*/
diff --git a/hw/xfree86/modes/xf86RandR12.c b/hw/xfree86/modes/xf86RandR12.c
index 9d7750f..caf6429 100644
--- a/hw/xfree86/modes/xf86RandR12.c
+++ b/hw/xfree86/modes/xf86RandR12.c
@@ -51,6 +51,8 @@ typedef struct _xf86RandR12Info {
intmmHeight;
intmaxX;
intmaxY;
+intpointerX;
+intpointerY;
Rotation rotation; /* current mode */
Rotationsupported_rotations; /* driver supported */
} XF86RandRInfoRec, *XF86RandRInfoPtr;
@@ -86,6 +88,85 @@ xf86RandR12ModeRefresh (DisplayModePtr mode)
return (int) (mode->Clock * 1000.0 / mode->HTotal / mode->VTotal + 0.5);
}
+static int
+xf86RandR13VerifyPanningArea (xf86CrtcPtr crtc, int screenWidth, int
screenHeight)
+{
+if (crtc->version < 2)
+ return FALSE;
+
+if (crtc->panningTotalArea.x2 <= crtc->panningTotalArea.x1
||
+ crtc->panningTotalArea.y2 <= crtc->panningTotalArea.y1) {
+ memset (&crtc->panningTotalArea, 0, sizeof(BoxRec));
+ memset (&crtc->panningTrackingArea, 0, sizeof(BoxRec));
+ memset (&crtc->panningBorder, 0, 4*sizeof(INT16));
+ return TRUE;
+}
+
+if (crtc->panningTotalArea.x2 <= crtc->panningTotalArea.x1
||
+ crtc->panningTotalArea.y2 <= crtc->panningTotalArea.y1
||
+ crtc->panningTotalArea.x1 < 0
||
+ crtc->panningTotalArea.y1 < 0
||
+ crtc->panningTotalArea.x2 < crtc->panningTotalArea.x1 +
crtc->mode.HDisplay ||
+ crtc->panningTotalArea.y2 < crtc->panningTotalArea.y1 +
crtc->mode.VDisplay ||
+ crtc->panningTotalArea.x2 > screenWidth
||
+ crtc->panningTotalArea.y2 > screenHeight)
+{
+ memset (&crtc->panningTotalArea, 0, sizeof(BoxRec));
+ memset (&crtc->panningTrackingArea, 0, sizeof(BoxRec));
+ memset (&crtc->panningBorder, 0, 4*sizeof(INT16));
+ return FALSE;
+}
+if (crtc->panningBorder[0] + crtc->panningBorder[2] > crtc->mode.HDisplay
||
+ crtc->panningBorder[1] + crtc->panningBorder[3] > crtc->mode.VDisplay) {
+ memset (&crtc->panningBorder, 0, 4*sizeof(INT16));
+ return FALSE;
+}
+return TRUE;
+}
+
+static void
+xf86RandR13Pan (xf86CrtcPtr crtc, int x, int y)
+{
+int newX, newY;
+int width, height;
+
+if (crtc->version < 2)
+ return;
+
+if (! crtc->enabled||
+ crtc->panningTotalArea.x2 <= crtc->panningTotalArea.x1 ||
+ crtc->panningTotalArea.y2 <= crtc->panningTotalArea.y1)
+ return;
+
+newX = crtc->x;
+newY = crtc->y;
+width = crtc->mode.HDisplay;
+height = crtc->mode.VDisplay;
+
+if (x >= crtc->panningTrackingArea.x1 && x < crtc->panningTrackingArea.x2
&&
+ y >= crtc->panningTrackingArea.y1 && y < crtc->panningTrackingArea.y2) {
+ if (x < crtc->x + crtc->panningBorder[0])
+ newX = x - crtc->panningBorder[0];
+ if (x >= crtc->x + width - crtc->panningBorder[2])
+ newX = x - width + crtc->panningBorder[2] + 1;
+ if (y < crtc->y + crtc->panningBorder[1])
+ ne
[PATCH 02/13] randrproto: Panning protocol description
--- randrproto.txt | 110 1 files changed, 110 insertions(+), 0 deletions(-) diff --git a/randrproto.txt b/randrproto.txt index 58c9e40..458c5f9 100644 --- a/randrproto.txt +++ b/randrproto.txt @@ -508,6 +508,13 @@ dynamic changes in the display environment. extension and the core protocol. They must be non-zero, or Value error results. + Note that changes to the screen size might invalidate panning + parameters. In these cases panning might be silently disabled, or the + panning parameters are updated automatically as necessary. The exact + behavior of the implementation is undefined. If the panning parameters + do not conflict with new screen size, panning remains enabled + unchanged. + ââââ RRGetScreenResources window: WINDOW @@ -938,6 +945,12 @@ dynamic changes in the display environment. then re-enabling the CRTC at the new configuration to avoid an invalid intermediate configuration. + Note that changes to the CRTC might invalidate panning parameters. In + these cases panning might be silently disabled, or the panning + parameters are updated automatically as necessary. The exact behavior + of the implementation is undefined. If the panning parameters do not + conflict with new CRTC parameters, panning remains enabled unchanged. + When this request succeeds, 'status' contains Success and the requested changes to configuration will have been made. @@ -1059,6 +1072,103 @@ This request returns the pending and current transforms for the specified CRTC. The pending transform will be the same as the current transform if no new pending transform has been set since the last call to RRSetCrtcConfig. +ââââ +RRGetPanning + crtc: CRTC + config-timestamp: TIMESTAMP + ⶠ+ status: RRCONFIGSTATUS + timestamp: TIMESTAMP + left, top, width, height: CARD16 + track_left, track_top, track_width, track_height: CARD16 + border_left, border_top, border_right, border_bottom: INT16 +ââââ + + Errors: Crtc + + Version 1.3 adds panning support again. If multiple crtcs are active + the panning behavior can be defined per crtc individually. + RRGetPanning returns information about the currently set panning + configuration for the specified crtc. + + If 'config-timestamp' does not match the current configuration + timestamp (as returned by RRGetScreenResources), 'status' is set to + InvalidConfigTime and the remaining reply data is empty. Otherwise, + 'status' is set to Success. + + 'timestamp' indicates when the configuration was last set. + + All other entries are explained for RRSetPanning. + +ââââ +RRSetPanning + crtc: CRTC + timestamp: TIMESTAMP + config-timestamp: TIMESTAMP + left, top, width, height: CARD16 + track_left, track_top, track_width, track_height: CARD16 + border_left, border_top, border_right, border_bottom: INT16 + ⶠ+ status: RRCONFIGSTATUS + new-timestamp: TIMESTAMP +ââââ + Errors: Crtc, Match + + If 'timestamp' is less than the time when the configuration was last + successfully set, the request is ignored and InvalidTime returned in + status. + + If 'config-timestamp' is not equal to when the CRTC's configuration + last changed, the request is ignored and InvalidConfigTime returned in + status. This could occur if the CRTC changed since you last made a + RRGetCrtcInfo request, perhaps by setting a different mode. Rather + than allowing an incorrect call to be executed based on stale data, + the server will ignore the request. + + 'left', 'top', 'width', and 'height' contain the total panning area + for this CRTC. 'width' has to be larger than the CRTC's width, and + 'left'+'width' must be within the screen size, else a Match error + results. Equivalent restrictions for the height exist. The exception + is 'width' == 'height' == 0 which indicates that panning should be + disabled. + + 'track_left', 'track_top', 'track_width', and 'track_height' contain + the pointer area for which the panning region is updated. For normal + use cases it should enclose the panning area minus borders, and is + typically set to either the panning area minus borders, or to the + total screen size. If set to the total screen size, the CRTC will pan + in the remaining axis even if the pointer is outside the panning area + on a different CRTC. + + 'border_left', 'border_top', 'border_right', and 'border_bottom' + define the distances from the CRTC borders that will activate panning + if the pointer hits them. If the borders are 0, the screen wil
[PATCH 12/12] xrandr: Bump version to 1.3.0, RandR requirements to 1.3.0.
--- configure.ac |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/configure.ac b/configure.ac index 126a51b..9be14c0 100644 --- a/configure.ac +++ b/configure.ac @@ -21,7 +21,7 @@ dnl dnl Process this file with autoconf to create configure. AC_PREREQ([2.57]) -AC_INIT(xrandr,[1.2.3], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg],xrandr) +AC_INIT(xrandr,[1.3.0], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg],xrandr) AM_INIT_AUTOMAKE([dist-bzip2]) AM_MAINTAINER_MODE @@ -31,7 +31,7 @@ AC_PROG_CC AC_PROG_INSTALL # Checks for pkg-config packages -PKG_CHECK_MODULES(XRANDR, xrandr >= 1.2.0 xrender x11) +PKG_CHECK_MODULES(XRANDR, xrandr >= 1.3.0 xrender x11) AC_SUBST(XRANDR_CFLAGS) AC_SUBST(XRANDR_LIBS) -- 1.5.6 ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[PATCH 13/13] xf86-video-radeonhd: RandR 1.3 Panning support
---
src/rhd_randr.c | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/src/rhd_randr.c b/src/rhd_randr.c
index 62b5e74..fc0439f 100644
--- a/src/rhd_randr.c
+++ b/src/rhd_randr.c
@@ -499,6 +499,14 @@ rhdRRCrtcModeFixupDUMMY(xf86CrtcPtrcrtc,
return TRUE;
}
+static void
+rhdRRCrtcPan(xf86CrtcPtr crtc, int x, int y)
+{
+struct rhdCrtc *rhdCrtc = ((struct rhdRandrCrtc*)
(crtc->driver_private))->rhdCrtc;
+
+rhdCrtc->FrameSet(rhdCrtc, x, y);
+}
+
/*
* xf86Output callback functions
@@ -1531,6 +1539,10 @@ static xf86CrtcFuncsRec rhdRRCrtcFuncs = {
/* set_mode_major */
, NULL
#endif
+#if XF86_CRTC_VERSION >= 2
+/* pan */
+, rhdRRCrtcPan
+#endif
};
/*
--
1.5.6
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
[PATCH 08/13] xserver: randr: Crtc interface update for panning support.
---
hw/xfree86/modes/xf86Crtc.h | 36 +++-
1 files changed, 35 insertions(+), 1 deletions(-)
diff --git a/hw/xfree86/modes/xf86Crtc.h b/hw/xfree86/modes/xf86Crtc.h
index 4b6f7d2..f085bf7 100644
--- a/hw/xfree86/modes/xf86Crtc.h
+++ b/hw/xfree86/modes/xf86Crtc.h
@@ -213,9 +213,16 @@ typedef struct _xf86CrtcFuncs {
Bool
(*set_mode_major)(xf86CrtcPtr crtc, DisplayModePtr mode,
Rotation rotation, int x, int y);
+
+/**
+ * Callback for panning. Doesn't change the mode.
+ */
+void
+(*pan)(xf86CrtcPtr crtc, int x, int y);
+
} xf86CrtcFuncsRec, *xf86CrtcFuncsPtr;
-#define XF86_CRTC_VERSION 1
+#define XF86_CRTC_VERSION 2
struct _xf86Crtc {
/**
@@ -321,6 +328,15 @@ struct _xf86Crtc {
* Bounding box in screen space
*/
BoxRec bounds;
+/**
+ * Panning:
+ * TotalArea: total panning area, larger than CRTC's size
+ * TrackingArea: Area of the pointer for which the CRTC is panned
+ * border: Borders of the displayed CRTC area which induces panning if the
pointer reaches them
+ */
+BoxRec panningTotalArea;
+BoxRec panningTrackingArea;
+INT16 panningBorder[4];
};
typedef struct _xf86OutputFuncs {
@@ -678,6 +694,9 @@ Bool
xf86CrtcSetMode (xf86CrtcPtr crtc, DisplayModePtr mode, Rotation rotation,
int x, int y);
+void
+xf86CrtcPan (xf86CrtcPtr crtc, int x, int y);
+
/*
* Assign crtc rotation during mode set
*/
@@ -867,4 +886,19 @@ xf86_unwrap_crtc_notify(ScreenPtr pScreen,
xf86_crtc_notify_proc_ptr old);
void
xf86_crtc_notify(ScreenPtr pScreen);
+/**
+ * Panning
+ */
+Bool
+xf86_crtc_get_panning(ScrnInfoPtr pScrn,
+ BoxPtr totalArea,
+ BoxPtr TrackingArea,
+ INT16 *border);
+
+Bool
+xf86_crtc_set_panning(ScrnInfoPtr pScrn,
+ BoxPtr totalArea,
+ BoxPtr TrackingArea,
+ INT16 *border);
+
#endif /* _XF86CRTC_H_ */
--
1.5.6
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
[PATCH 11/12] xrandr: Add panning support.
---
xrandr.c | 114 +-
1 files changed, 113 insertions(+), 1 deletions(-)
diff --git a/xrandr.c b/xrandr.c
index b1e133e..9dcd72a 100644
--- a/xrandr.c
+++ b/xrandr.c
@@ -131,6 +131,7 @@ usage(void)
fprintf(stderr, " --set \n");
fprintf(stderr, " --off\n");
fprintf(stderr, " --crtc \n");
+fprintf(stderr, " --panning
x[++[/x++[]]]\n");
fprintf(stderr, " --newmode \n");
fprintf(stderr, "
\n");
fprintf(stderr, "
\n");
@@ -207,6 +208,7 @@ typedef enum _changes {
changes_automatic = (1 << 6),
changes_refresh = (1 << 7),
changes_property = (1 << 8),
+changes_panning = (1 << 9),
} changes_t;
typedef enum _name_kind {
@@ -235,6 +237,7 @@ struct _crtc {
XRRCrtcInfo*crtc_info;
XRRModeInfo*mode_info;
+XRRPanning *panning_info;
intx;
inty;
Rotation rotation;
@@ -274,6 +277,8 @@ struct _output {
intx, y;
Rotation rotation;
+char*panning;
+
Bool automatic;
};
@@ -322,6 +327,7 @@ static char *dpi_output = NULL;
static Booldryrun = False;
static int minWidth, maxWidth, minHeight, maxHeight;
static Boolhas_1_2 = False;
+static Boolhas_1_3 = False;
static int
mode_height (XRRModeInfo *mode_info, Rotation rotation)
@@ -871,10 +877,16 @@ get_crtcs (void)
for (c = 0; c < res->ncrtc; c++)
{
XRRCrtcInfo *crtc_info = XRRGetCrtcInfo (dpy, res, res->crtcs[c]);
+ XRRPanning *panning_info = NULL;
+
+ if (has_1_3)
+ panning_info = XRRGetPanning (dpy, res, res->crtcs[c]);
+
set_name_xid (&crtcs[c].crtc, res->crtcs[c]);
set_name_index (&crtcs[c].crtc, c);
if (!crtc_info) fatal ("could not get crtc 0x%x information",
res->crtcs[c]);
crtcs[c].crtc_info = crtc_info;
+ crtcs[c].panning_info = panning_info;
if (crtc_info->mode == None)
{
crtcs[c].mode_info = NULL;
@@ -914,6 +926,55 @@ set_crtcs (void)
}
}
+static void
+crtc_set_panning (crtc_t *crtc, char *panning)
+{
+XRRPanning *pan = crtc->panning_info;
+
+if (!pan)
+ pan = malloc (sizeof(XRRPanning));
+memset (pan, 0, sizeof(XRRPanning));
+
+switch (sscanf (panning, "%dx%d+%d+%d/%dx%d+%d+%d/%d/%d/%d/%d",
+ &pan->width, &pan->height, &pan->left, &pan->top,
+ &pan->track_width, &pan->track_height,
+ &pan->track_left, &pan->track_top,
+ &pan->border_left, &pan->border_top,
+ &pan->border_right, &pan->border_bottom)) {
+case 2:
+ pan->left = pan->top = 0;
+ /* fall through */
+case 4:
+ pan->track_left = pan->left;
+ pan->track_top= pan->top;
+ pan->track_width = pan->width;
+ pan->track_height = pan->height;
+ /* fall through */
+case 8:
+ pan->border_left = pan->border_top =
+ pan->border_right = pan->border_bottom = 0;
+ /* fall through */
+case 12:
+ break;
+default:
+ usage ();
+}
+crtc->changing = 1;
+}
+
+static void
+set_panning (void)
+{
+output_t *output;
+
+for (output = outputs; output; output = output->next)
+{
+ if (!output->panning) continue;
+ if (!output->crtc_info) fatal ("no crtc assigned");
+ crtc_set_panning (output->crtc_info, output->panning);
+}
+}
+
static Status
crtc_disable (crtc_t *crtc)
{
@@ -970,10 +1031,17 @@ crtc_apply (crtc_t *crtc)
if (dryrun)
s = RRSetConfigSuccess;
-else
+else {
s = XRRSetCrtcConfig (dpy, res, crtc->crtc.xid, CurrentTime,
crtc->x, crtc->y, mode, crtc->rotation,
rr_outputs, crtc->noutput);
+ if (s == RRSetConfigSuccess && crtc->panning_info) {
+ if (has_1_3)
+ s = XRRSetPanning (dpy, res, crtc->crtc.xid,
crtc->panning_info);
+ else
+ fatal ("panning needs RandR 1.3");
+ }
+}
free (rr_outputs);
return s;
}
@@ -1841,6 +1909,13 @@ main (int argc, char **argv)
output->changes |= changes_relation;
continue;
}
+ if (!strcmp ("--panning", argv[i])) {
+ if (++i>=argc) usage ();
+ if (!output) usage();
+ output->panning = argv[i];
+ output->changes |= changes_panning;
+ continue;
+ }
if (!strcmp ("--set", argv[i])) {
output_prop_t *prop;
if (!output) usage();
@@ -2035,6 +2110,8 @@ main (int argc, char **argv)
}
if (major > 1 || (major == 1 && minor >= 2))
has_1_2 = True;
+if (major > 1 || (major == 1 && minor >= 3))
+ has_1_3 = True;
if (has_1_2 && mod
[PATCH 03/13] randrproto: Panning protocol bits description
--- randrproto.txt | 55 +++ 1 files changed, 55 insertions(+), 0 deletions(-) diff --git a/randrproto.txt b/randrproto.txt index 458c5f9..1bc0416 100644 --- a/randrproto.txt +++ b/randrproto.txt @@ -1960,6 +1960,61 @@ A.2.2 Protocol Requests added with version 1.3 4*cfFIXED current filter params ââââ +ââââ +RRGetPanning + 1 CARD8 major opcode + 1 28 RandR opcode + 2 3 length + 4 CRTCcrtc + 4 TIMESTAMP config-timestamp + ⶠ+ 1 1 Reply + 1 RRCONFIGSTATUS status + 2 CARD16 sequence number + 4 1 reply length + 4 TIMESTAMP timestamp + 2 CARD16 left + 2 CARD16 top + 2 CARD16 width + 2 CARD16 height + 2 CARD16 track_left + 2 CARD16 track_top + 2 CARD16 track_width + 2 CARD16 track_height + 2 INT16 border_left + 2 INT16 border_top + 2 INT16 border_right + 2 INT16 border_bottom +ââââ +ââââ +RRSetPanning + 1 CARD8 major opcode + 1 29 RandR opcode + 2 10 length + 4 CRTCcrtc + 4 TIMESTAMP timestamp + 4 TIMESTAMP config-timestamp + 2 CARD16 left + 2 CARD16 top + 2 CARD16 width + 2 CARD16 height + 2 CARD16 track_left + 2 CARD16 track_top + 2 CARD16 track_width + 2 CARD16 track_height + 2 INT16 border_left + 2 INT16 border_top + 2 INT16 border_right + 2 INT16 border_bottom + ⶠ+ 1 1 Reply + 1 RRCONFIGSTATUS status + 2 CARD16 sequence number + 4 0 reply length + 4 TIMESTAMP new timestamp + 20 unused +ââââ + A.3 Protocol Events ââââ -- 1.5.6 ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[PATCH 01/13] randrproto: Panning protocol extension
---
randr.h |4 ++-
randrproto.h | 66 ++
2 files changed, 69 insertions(+), 1 deletions(-)
diff --git a/randr.h b/randr.h
index 87cd4a8..92f2fb6 100644
--- a/randr.h
+++ b/randr.h
@@ -44,7 +44,7 @@ typedef unsigned long XRandrModeFlags;
#define RRNumberErrors 3
#define RRNumberEvents 2
-#define RRNumberRequests 28
+#define RRNumberRequests 30
#define X_RRQueryVersion 0
/* we skip 1 to make old clients fail pretty immediately */
@@ -82,6 +82,8 @@ typedef unsigned long XRandrModeFlags;
#define X_RRGetScreenResourcesCurrent 25
#define X_RRSetCrtcTransform 26
#define X_RRGetCrtcTransform 27
+#define X_RRGetPanning 28
+#define X_RRSetPanning 29
#define RRTransformUnit(1L << 0)
#define RRTransformScaleUp (1L << 1)
diff --git a/randrproto.h b/randrproto.h
index f8aac94..324455e 100644
--- a/randrproto.h
+++ b/randrproto.h
@@ -700,6 +700,72 @@ typedef struct {
} xRROutputPropertyNotifyEvent;
#define sz_xRROutputPropertyNotifyEvent32
+typedef struct {
+CARD8 reqType;
+CARD8 randrReqType;
+CARD16 length B16;
+RRCrtc crtc B32;
+Time configTimestamp B32;
+} xRRGetPanningReq;
+#define sz_xRRGetPanningReq12
+
+typedef struct {
+BYTE type;
+CARD8 status;
+CARD16 sequenceNumber B16;
+CARD32 length B32;
+Time timestamp B32;
+CARD16 left B16;
+CARD16 top B16;
+CARD16 width B16;
+CARD16 height B16;
+CARD16 track_left B16;
+CARD16 track_top B16;
+CARD16 track_width B16;
+CARD16 track_height B16;
+INT16 border_left B16;
+INT16 border_top B16;
+INT16 border_right B16;
+INT16 border_bottom B16;
+} xRRGetPanningReply;
+#define sz_xRRGetPanningReply 36
+
+typedef struct {
+CARD8 reqType;
+CARD8 randrReqType;
+CARD16 length B16;
+RRCrtc crtc B32;
+Time timestamp B32;
+Time configTimestamp B32;
+CARD16 left B16;
+CARD16 top B16;
+CARD16 width B16;
+CARD16 height B16;
+CARD16 track_left B16;
+CARD16 track_top B16;
+CARD16 track_width B16;
+CARD16 track_height B16;
+INT16 border_left B16;
+INT16 border_top B16;
+INT16 border_right B16;
+INT16 border_bottom B16;
+} xRRSetPanningReq;
+#define sz_xRRSetPanningReq40
+
+typedef struct {
+BYTE type;
+CARD8 status;
+CARD16 sequenceNumber B16;
+CARD32 length B32;
+Time newTimestamp B32;
+CARD32 pad1 B32;
+CARD32 pad2 B32;
+CARD32 pad3 B32;
+CARD32 pad4 B32;
+CARD32 pad5 B32;
+} xRRSetPanningReply;
+#define sz_xRRSetPanningReply 32
+
#undef RRModeFlags
#undef RRCrtc
#undef RRMode
--
1.5.6
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
[PATCH 05/13] libXrandr: Panning support
---
include/X11/extensions/Xrandr.h | 28 +++
src/XrrCrtc.c | 97 +++
2 files changed, 125 insertions(+), 0 deletions(-)
diff --git a/include/X11/extensions/Xrandr.h b/include/X11/extensions/Xrandr.h
index 77a7d04..e9fa94e 100644
--- a/include/X11/extensions/Xrandr.h
+++ b/include/X11/extensions/Xrandr.h
@@ -378,6 +378,34 @@ XRRFreeGamma (XRRCrtcGamma *gamma);
*/
int XRRUpdateConfiguration(XEvent *event);
+typedef struct _XRRPanning {
+Timetimestamp;
+unsigned int left;
+unsigned int top;
+unsigned int width;
+unsigned int height;
+unsigned int track_left;
+unsigned int track_top;
+unsigned int track_width;
+unsigned int track_height;
+int border_left;
+int border_top;
+int border_right;
+int border_bottom;
+} XRRPanning;
+
+XRRPanning *
+XRRGetPanning (Display *dpy, XRRScreenResources *resources, RRCrtc crtc);
+
+void
+XRRFreePanning (XRRPanning *panning);
+
+Status
+XRRSetPanning (Display *dpy,
+ XRRScreenResources *resources,
+ RRCrtc crtc,
+ XRRPanning *panning);
+
_XFUNCPROTOEND
#endif /* _XRANDR_H_ */
diff --git a/src/XrrCrtc.c b/src/XrrCrtc.c
index 5e5c813..f6fe4c0 100644
--- a/src/XrrCrtc.c
+++ b/src/XrrCrtc.c
@@ -270,3 +270,100 @@ XRRFreeGamma (XRRCrtcGamma *crtc_gamma)
{
Xfree (crtc_gamma);
}
+
+XRRPanning *
+XRRGetPanning (Display *dpy, XRRScreenResources *resources, RRCrtc crtc)
+{
+XExtDisplayInfo*info = XRRFindDisplay(dpy);
+xRRGetPanningReply rep;
+xRRGetPanningReq *req;
+XRRPanning *xp;
+
+RRCheckExtension (dpy, info, 0);
+
+LockDisplay (dpy);
+GetReq (RRGetPanning, req);
+req->reqType = info->codes->major_opcode;
+req->randrReqType= X_RRGetPanning;
+req->crtc= crtc;
+req->configTimestamp = resources->configTimestamp;
+
+if (!_XReply (dpy, (xReply *) &rep, 1, xFalse))
+{
+ UnlockDisplay (dpy);
+ SyncHandle ();
+ return NULL;
+}
+
+if (! (xp = (XRRPanning *) Xmalloc(sizeof(XRRPanning))) ) {
+ _XEatData (dpy, sizeof(XRRPanning));
+ UnlockDisplay (dpy);
+ SyncHandle ();
+ return NULL;
+}
+
+xp->timestamp = rep.timestamp;
+xp->left = rep.left;
+xp->top = rep.top;
+xp->width = rep.width;
+xp->height= rep.height;
+xp->track_left= rep.track_left;
+xp->track_top = rep.track_top;
+xp->track_width = rep.track_width;
+xp->track_height = rep.track_height;
+xp->border_left = rep.border_left;
+xp->border_top= rep.border_top;
+xp->border_right = rep.border_right;
+xp->border_bottom = rep.border_bottom;
+
+UnlockDisplay (dpy);
+SyncHandle ();
+return (XRRPanning *) xp;
+}
+
+void
+XRRFreePanning (XRRPanning *panning)
+{
+Xfree (panning);
+}
+
+Status
+XRRSetPanning (Display *dpy,
+ XRRScreenResources *resources,
+ RRCrtc crtc,
+ XRRPanning *panning)
+{
+XExtDisplayInfo*info = XRRFindDisplay(dpy);
+xRRSetPanningReply rep;
+xRRSetPanningReq *req;
+inti;
+
+RRCheckExtension (dpy, info, 0);
+
+LockDisplay(dpy);
+GetReq (RRSetPanning, req);
+req->reqType = info->codes->major_opcode;
+req->randrReqType = X_RRSetPanning;
+req->crtc = crtc;
+req->timestamp = panning->timestamp;
+req->configTimestamp = resources->configTimestamp;
+req->left = panning->left;
+req->top = panning->top;
+req->width = panning->width;
+req->height= panning->height;
+req->track_left= panning->track_left;
+req->track_top = panning->track_top;
+req->track_width = panning->track_width;
+req->track_height = panning->track_height;
+req->border_left = panning->border_left;
+req->border_top= panning->border_top;
+req->border_right = panning->border_right;
+req->border_bottom = panning->border_bottom;
+
+if (!_XReply (dpy, (xReply *) &rep, 0, xFalse))
+ rep.status = RRSetConfigFailed;
+UnlockDisplay (dpy);
+SyncHandle ();
+return rep.status;
+}
+
--
1.5.6
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
[PATCH 10/13] xserver: randr: Protocol bits for panning support
---
randr/randrstr.h | 19 ++
randr/rrcrtc.c | 167
randr/rrdispatch.c |2 +
3 files changed, 188 insertions(+), 0 deletions(-)
diff --git a/randr/randrstr.h b/randr/randrstr.h
index 64206e8..f6aa5c7 100644
--- a/randr/randrstr.h
+++ b/randr/randrstr.h
@@ -190,6 +190,17 @@ typedef void (*RRModeDestroyProcPtr) (ScreenPtr
pScreen,
typedef Bool (*RROutputGetPropertyProcPtr) (ScreenPtr pScreen,
RROutputPtr output,
Atomproperty);
+typedef Bool (*RRGetPanningProcPtr)(ScreenPtr pScrn,
+ RRCrtcPtr crtc,
+ BoxPtr totalArea,
+ BoxPtr trackingArea,
+ INT16 *border);
+typedef Bool (*RRSetPanningProcPtr)(ScreenPtr pScrn,
+ RRCrtcPtr crtc,
+ BoxPtr totalArea,
+ BoxPtr trackingArea,
+ INT16 *border);
+
#endif /* RANDR_13_INTERFACE */
typedef Bool (*RRGetInfoProcPtr) (ScreenPtr pScreen, Rotation *rotations);
@@ -239,6 +250,8 @@ typedef struct _rrScrPriv {
#endif
#if RANDR_13_INTERFACE
RROutputGetPropertyProcPtr rrOutputGetProperty;
+RRGetPanningProcPtrrrGetPanning;
+RRSetPanningProcPtrrrSetPanning;
#endif
/*
@@ -686,6 +699,12 @@ ProcRRSetCrtcTransform (ClientPtr client);
int
ProcRRGetCrtcTransform (ClientPtr client);
+int
+ProcRRGetPanning (ClientPtr client);
+
+int
+ProcRRSetPanning (ClientPtr client);
+
/* rrdispatch.c */
Bool
RRClientKnowsRates (ClientPtr pClient);
diff --git a/randr/rrcrtc.c b/randr/rrcrtc.c
index 5d270ce..47a585c 100644
--- a/randr/rrcrtc.c
+++ b/randr/rrcrtc.c
@@ -978,6 +978,173 @@ sendReply:
}
int
+ProcRRGetPanning (ClientPtr client)
+{
+REQUEST(xRRGetPanningReq);
+xRRGetPanningReply rep;
+RRCrtcPtr crtc;
+ScreenPtr pScreen;
+rrScrPrivPtr pScrPriv;
+BoxRec total;
+BoxRec tracking;
+INT16 border[4];
+intn;
+
+REQUEST_SIZE_MATCH(xRRGetPanningReq);
+crtc = LookupCrtc(client, stuff->crtc, DixReadAccess);
+
+if (!crtc)
+ return RRErrorBase + BadRRCrtc;
+
+/* All crtcs must be associated with screens before client
+ * requests are processed
+ */
+pScreen = crtc->pScreen;
+pScrPriv = rrGetScrPriv(pScreen);
+
+if (!pScrPriv || !pScrPriv->rrGetPanning)
+ return RRErrorBase + BadRRCrtc;
+
+rep.type = X_Reply;
+rep.status = RRSetConfigSuccess;
+rep.sequenceNumber = client->sequence;
+rep.length = 1;
+rep.timestamp = pScrPriv->lastSetTime.milliseconds;
+
+if (! pScrPriv->rrGetPanning (pScreen, crtc, &total, &tracking, border))
+ return RRErrorBase + BadRRCrtc;
+
+rep.left = total.x1;
+rep.top = total.y1;
+rep.width = total.x2 - total.x1;
+rep.height= total.y2 - total.y1;
+rep.track_left= tracking.x1;
+rep.track_top = tracking.y1;
+rep.track_width = tracking.x2 - tracking.x1;
+rep.track_height = tracking.y2 - tracking.y1;
+rep.border_left = border[0];
+rep.border_top= border[1];
+rep.border_right = border[2];
+rep.border_bottom = border[3];
+
+if (client->swapped) {
+ swaps(&rep.sequenceNumber, n);
+ swapl(&rep.length, n);
+ swaps(&rep.timestamp, n);
+ swaps(&rep.left, n);
+ swaps(&rep.top, n);
+ swaps(&rep.width, n);
+ swaps(&rep.height, n);
+ swaps(&rep.track_left, n);
+ swaps(&rep.track_top, n);
+ swaps(&rep.track_width, n);
+ swaps(&rep.track_height, n);
+ swaps(&rep.border_left, n);
+ swaps(&rep.border_top, n);
+ swaps(&rep.border_right, n);
+ swaps(&rep.border_bottom, n);
+}
+WriteToClient(client, sizeof(xRRGetPanningReply), (char *)&rep);
+return client->noClientException;
+}
+
+int
+ProcRRSetPanning (ClientPtr client)
+{
+REQUEST(xRRSetPanningReq);
+xRRSetPanningReply rep;
+RRCrtcPtr crtc;
+ScreenPtr pScreen;
+rrScrPrivPtr pScrPriv;
+TimeStamp configTime;
+TimeStamp time;
+BoxRec total;
+BoxRec tracking;
+INT16 border[4];
+intn;
+
+REQUEST_SIZE_MATCH(xRRSetPanningReq);
+crtc = LookupCrtc(client, stuff->crtc, DixReadAccess);
+
+if (!crtc)
+ return RRErrorBase + BadRRCrtc;
+
+
+/* All crtcs must be associated with screens before client
+ * requests are process
