Re: DRI2 Protocol Spec Draft

On Mon, 2008-09-08 at 17:58 -0400, Kristian Høgsberg wrote: Hi, Keith talked me intro writing a spec for DRI2, which I grudgingly must admit is a good idea. I used the randr spec as a template, except I replaced the flowery section dividers with a more fitting gears motif. It's still a

Re: DRI2 Protocol Spec Draft

On Tue, 2008-09-09 at 13:27 +0200, Michel Dänzer wrote: I think it'd be good if the authentication stuff could be made/kept optional or at least not DRM specific. (I'm not sure GEM or the DRM in general is within scope of this spec at all) I have to admit that I'm not very excited by the

Re: DRI2 Protocol Spec Draft

On Wed, 2008-09-10 at 11:54 -0400, Kristian Høgsberg wrote: The buffer types available? This is for when you want to check if, say, a DRI2_BUFFER_YUV is available, and if not fall back to something else? I was thinking of the direct rendering libraries which it knows about, but yeah, the

Re: DRI2 Protocol Spec Draft

On Wed, 2008-09-10 at 17:28 -0400, Kristian Høgsberg wrote: No that's why the existing scheme is better, it doesn't rely on random/cryptographical tokens. It just needs to be a unique handle that lets the server identify the right client to authenticate. If you can pass this token to the X

Re: Building X

On Fri, 2008-09-19 at 15:02 +1000, Russell Shaw wrote: I think it would be a good idea if there was a default cursor present if nothing else. At least when using the ugly grey stipple. If you're using -br, the missing-cursor plan seems reasonable. Otherwise, it makes debugging X server startup

Re: A couple of composite fixes from Owen Taylor

On Fri, 2008-09-19 at 13:44 -0400, Owen Taylor wrote: Thanks for checking things out; I will go ahead and push them now. I guess I might quibble with the comment in the second one which makes it sounds like this has to do with exotic guffaw scrolling manipulations or something. Older window

Re: Various patches

On Thu, 2008-09-04 at 10:57 +0100, John Tapsell wrote: Hi all, The first patch applies to xorg/xserver and replaces the requirement of openssl with an internal SHA1 implementation. The SHA1 code is the code that openbsd uses and is public domain. Using an internal SHA1 implementation

RandR query state for Gnome

Right now, Gnome uses RandR to figure out the current screen configuration, but RandR probes the hardware, taking time and causing flashing. What we need is some way to get the info that gnome needs without also polling the hardware for what possible configurations there might be. This is

Re: [PATCH 2/4] X event queue mutex

On Wed, 2008-10-01 at 21:39 -0300, Tiago Vignatti wrote: A mutex is needed because the X event queue is a critical region. Though the X event queue is re-entrant, we cannot guarantee the simultaneous processing by both main and input threads. The input queue is written so that each user

Re: [PATCH 2/4] X event queue mutex

On Fri, 2008-10-03 at 02:01 +0200, Simon Thum wrote: It may be constructed, but IMO this means the queue size is not fully utilizable given head is 'old': Yes, that's fairly common in queues -- you often can't use the last entry. Not a huge deal if you make the queue big enough. BTW, given

Re: [PATCH 2/4] X event queue mutex

On Fri, 2008-10-03 at 05:57 +0300, Daniel Stone wrote: On Thu, Oct 02, 2008 at 06:53:09PM -0700, Keith Packard wrote: On Fri, 2008-10-03 at 02:01 +0200, Simon Thum wrote: (b) may suffice. Locking the queue in OsBlockSigs() should do it and fix most miEnqueue users. Or just lock

Re: problem with i830M interlaced VGA output (915G works fine)

On Sun, 2008-10-05 at 09:21 +0200, Thomas Hilber wrote: Hi list, with the attached patch and xorg.conf I successfully use interlaced modes like 720x576i on a 915G chipset. For an i830M this unfortunately does not yet work completely. First of all thanks to Keith Packard and Krzysztof

Re: problem with i830M interlaced VGA output (915G works fine)

On Mon, 2008-10-06 at 19:27 +0200, Thomas Hilber wrote: but it's quite strange. Even my i810 is running in interlaced mode (i.e. 720x576i) with exactly the patch above with no problems at all. Yeah, i810 is completely different than i830 and later. And, for some reason, i830 has no interlaced

Re: [PATCH 2/4] X event queue mutex

On Tue, 2008-10-07 at 00:46 -0300, Tiago Vignatti wrote: BTW, all mieqEnqueue() calls isn't needed to be wrapped by OsBlockSignals() and OsReleaseSignals()? This is not what is happening in our code. OsBlockSignals is only required when queuing events other than from the SIGIO handler as

Re: xserver: Branch 'master'

On Fri, 2008-10-10 at 14:12 -0400, Adam Jackson wrote: Yeah, that sounds like something I'd say. I am not the release bitch for 1.6 though. No strong feelings either way on the ABI number, personally. I'm doing 1.6, and I don't care about ABI numbers either; the only rule we should make is

Re: GMA X4500MHD with the intel-driver?

On Sat, 2008-10-11 at 20:23 +0200, Karsten Heiken wrote: Is there any chance of being able to use the internal display with the intel-driver? Even better: using both displays? ;-) Could you try master versions of the driver and libdrm? We're trying to finish up release 2.5 and GM45 issues are

Re: Render spec clarification

On Mon, 2008-10-13 at 11:01 -0400, Adam Jackson wrote: The former is certainly way simpler, but might break some existing application. Maybe? It's hard to imagine it breaking anything as the current server code does the wrong thing in this case. Given that 3D hardware doesn't support this

Re: 3d very slow on 945GM using intel driver

On Tue, 2008-10-21 at 01:09 +0100, Steven J Newbury wrote: On Mon, 2008-10-20 at 17:05 -0700, Keith Packard wrote: On Mon, 2008-10-20 at 15:11 +0200, Adam Lantos wrote: Same here w/i915. and glxgears shows only 70-75 fps... 70-75fps sounds like sync to vblank Not if it changes; vblank

Re: 3d very slow on 945GM using intel driver

On Tue, 2008-10-21 at 01:28 +0100, Steven J Newbury wrote: Yes, of course, but I assumed Adam meant 70-75 as in a value around that. I could easily be wrong in that assumption, it's clear he's having other problems. Yeah, hence my assumption that he's not getting HW accel, but you're right,

Re: modular: Changes to 'master'

On Tue, 2008-10-21 at 18:15 +0200, Luc Verhaegen wrote: Is there a single technical reason why shipping both is a problem? For the same reason the kernel avoids shipping multiple drivers for the same hardware -- we want a unique PCI-ID - driver mapping so that all X.org downstream users share

Re: [ANNOUNCE] xf86-video-intel 2.5.0

On Tue, 2008-10-21 at 18:33 +0200, samuel wrote: I've tried this driver now. doesn't seem to work here... gives me a fatal error and leaves my consoles in a non usable state... any suggestions? You need to apply the patch to the AGP driver in your kernel:

Re: xf86-video-intel 2.5.0 performance questions

On Wed, 2008-10-22 at 17:52 +0200, Halim Issa wrote: [drm:i915_getparam] *ERROR* Unknown parameter 5 set status page addr 0x01fff000 As Julien said, this is just the user-mode driver checking for GEM support which isn't present in your old kernel. If it were the new 2D driver printing the

[PATCH] Notify DRI when crtc regions change

updated information. Signed-off-by: Keith Packard [EMAIL PROTECTED] --- hw/xfree86/dri/Makefile.am |5 + hw/xfree86/dri/dri.c|5 + hw/xfree86/loader/xf86sym.c |1 + hw/xfree86/modes/xf86Crtc.c | 10 ++ hw/xfree86/modes/xf86Crtc.h |3 +++ 5 files changed

Re: [PATCH] Notify DRI when crtc regions change

On Tue, 2008-11-04 at 15:48 -0500, Adam Jackson wrote: I think it makes sense, although I'm kind of surprised we don't pick up on it from ClipNotify on the root window. Still rotation is basically a catastrophic clip change so might as well recompute the world. Rotation would hit ClipNotify,

Re: xf86-video-intel: suspend to ram does not work

On Sun, 2008-11-09 at 15:41 +0100, Christoph Schied wrote: Hi! My System crashes after resuming from suspend to ram. It shows the Xserver, but freezes then. When using xf86-video-vesa, suspend works without problems. I tried xf86-video-intel-{2.5.0,2.4.2} and the appropriate xserver

[PATCH] Xinput: Use floats for ConstantDeceleration and AdaptiveDeceleration

These values need not be constrained to integer values. Signed-off-by: Keith Packard [EMAIL PROTECTED] --- hw/xfree86/common/xf86Xinput.c |8 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/hw/xfree86/common/xf86Xinput.c b/hw/xfree86/common/xf86Xinput.c index f028a25

[PATCH] Randr now depends on Render for matrices

--- configure.ac |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/configure.ac b/configure.ac index 90cacd7..5e1f860 100644 --- a/configure.ac +++ b/configure.ac @@ -1191,7 +1191,7 @@ AC_MSG_RESULT([$XNEST]) AM_CONDITIONAL(XNEST, [test x$XNEST = xyes]) if test x$XNEST

[PATCH] Add funcs to convert between protocol and pixman matrices

--- render/matrix.c | 36 +++- render/picturestr.h | 11 --- 2 files changed, 43 insertions(+), 4 deletions(-) diff --git a/render/matrix.c b/render/matrix.c index bd584cb..a976304 100644 --- a/render/matrix.c +++ b/render/matrix.c @@ -222,7 +222,7

[PATCH] [render] Split out filter finding from filter setting.

To prepare for RandR using filters in transforms, split out code paths so that the RandR code can validate the filter name and parameters during the transform set operation so that use of the filter later will not have unreportable errors. --- render/filter.c | 57

[PATCH] Adjust transformed cursor position to account for hotspot

--- hw/xfree86/modes/xf86Cursors.c |9 + 1 files changed, 9 insertions(+), 0 deletions(-) diff --git a/hw/xfree86/modes/xf86Cursors.c b/hw/xfree86/modes/xf86Cursors.c index a7ed5c4..7bf9265 100644 --- a/hw/xfree86/modes/xf86Cursors.c +++ b/hw/xfree86/modes/xf86Cursors.c @@ -37,6

[PATCH] Compute matrix inversion instead of using wire version in RRCrtcTransformSet

It doesn't make sense to have the client invert this matrix when the server can do so reasonably efficiently. This avoids weird fixed point rounding errors when testing the transform against its inverse. Now to fix the protocol. --- randr/rrcrtc.c |5 ++--- 1 files changed, 2 insertions(+), 3

[PATCH] Clear shadow pixmaps before using them.

This eliminates some ugly flashing, as well as clearing the borders when the shadow will not be completely painted. --- hw/xfree86/modes/xf86Rotate.c | 30 ++ 1 files changed, 30 insertions(+), 0 deletions(-) diff --git a/hw/xfree86/modes/xf86Rotate.c

[PATCH] Eliminate inverse matrix from randr transform protocol

It is easier, and potentially more precise, to compute the inverse in the server where everything can eventually be kept in floating point form. --- randr/rrcrtc.c |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/randr/rrcrtc.c b/randr/rrcrtc.c index 6559d51..e0fafce

[PATCH] Wire up RandR CRTC transform protocol, bump server to RandR 1.3

This involved removing a pile of matrix code from the DDX, as well as moving a bit of transform logic from DDX to DIX. --- hw/xfree86/modes/xf86Crtc.c|4 + hw/xfree86/modes/xf86RandR12.c |3 + hw/xfree86/modes/xf86Rotate.c | 212 +---

[PATCH] [randr] don't try to compute crtc transform when no mode is set.

Dereferencing the NULL mode pointer would cause a crash. As these transform matrices won't be used while the CRTC is disabled, just leave their values alone. --- randr/rrcrtc.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/randr/rrcrtc.c b/randr/rrcrtc.c index

[PATCH] Fix rotated/reflected cursor positions.

Doing projective transforms required repositioning the cursor using the hotspot, but that requires relocating the upper left corner in terms of said hotspot. --- hw/xfree86/modes/xf86Cursors.c | 22 +++--- 1 files changed, 11 insertions(+), 11 deletions(-) diff --git

[PATCH] rrtransform needs randrstr to get RANDR_INTERFACE defines

--- randr/rrtransform.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/randr/rrtransform.c b/randr/rrtransform.c index f9934d7..836a7ae 100644 --- a/randr/rrtransform.c +++ b/randr/rrtransform.c @@ -20,6 +20,7 @@ * OF THIS SOFTWARE. */ +#include randrstr.h

[PATCH] Handle RandR transform matrices in floating point.

RandR matrix computations lose too much precision in fixed point; computations using the inverted matrix can be as much as 10 pixels off. Convert them to double precision values and pass those around. These API changes are fairly heavyweight; the official Render interface remains fixed point, so

[PATCH] Export rrtransform.h as needed by randrstr.h

When the transform management was moved from randrstr.h, the associated header file became necessary to build drivers. Include it as a part of the sdk headers. --- randr/Makefile.am |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/randr/Makefile.am b/randr/Makefile.am

[PATCH] Handle transform failure when computing shadow damage area.

PictureTransformBounds can fail, when this happens, damage the entire screen so that the shadow gets repainted correctly. --- hw/xfree86/modes/xf86Rotate.c | 49 + render/matrix.c |7 +++-- render/picturestr.h |2 +- 3

[PATCH] [RANDR] Support filters in CRTC transforms.

Create new RRTransform datatype to hold all of the transform related information, use that in lots of places to pass filters around. --- hw/xfree86/modes/xf86Crtc.h |3 + hw/xfree86/modes/xf86Rotate.c | 31 +- randr/randrstr.h | 27 +++-- randr/rrcrtc.c|

[PATCH] Pass filter kernel size through transforms

--- randr/randrstr.h |2 ++ randr/rrcrtc.c | 28 ++-- 2 files changed, 20 insertions(+), 10 deletions(-) diff --git a/randr/randrstr.h b/randr/randrstr.h index cdaebe9..17d0a8b 100644 --- a/randr/randrstr.h +++ b/randr/randrstr.h @@ -111,6 +111,8 @@ struct

[PATCH] Add kernel size to Render filters.

This width/height value lets filter users know how far the filter spreads into the source image. --- render/filter.c | 27 --- render/picturestr.h |8 ++-- 2 files changed, 26 insertions(+), 9 deletions(-) diff --git a/render/filter.c b/render/filter.c index

[PATCH] Initialize and cleanup new filter fields in xf86Crtc.

--- hw/xfree86/modes/xf86Crtc.c | 12 1 files changed, 12 insertions(+), 0 deletions(-) diff --git a/hw/xfree86/modes/xf86Crtc.c b/hw/xfree86/modes/xf86Crtc.c index a40bf18..35c1190 100644 --- a/hw/xfree86/modes/xf86Crtc.c +++ b/hw/xfree86/modes/xf86Crtc.c @@ -103,6 +103,16 @@

[PATCH] Correct bilinear filter kernel size (should be 2x2)

--- render/filter.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/render/filter.c b/render/filter.c index b5bcf02..21eedca 100644 --- a/render/filter.c +++ b/render/filter.c @@ -252,7 +252,7 @@ PictureSetDefaultFilters (ScreenPtr pScreen) return FALSE;

[PATCH] When converting from double to fixed, round carefully.

This reduces the matrix representation error after inverting a transformation matrix (although it doesn't eliminate it entirely). Perhaps we should extend Render to include 64-bit floating point transforms... --- render/matrix.c |7 --- 1 files changed, 4 insertions(+), 3 deletions(-)

[PATCH] Add matrix inversion function (uses doubles)

The obvious matrix inversion function, coded using doubles to avoid fiddling with fixed point precision adventures. --- render/matrix.c | 80 +++ render/picturestr.h |3 ++ 2 files changed, 83 insertions(+), 0 deletions(-) diff --git

[PATCH] Report whether transforms are support from driver through extension to client

Add APIs to xf86RandR12 support and randr extension to record whether the driver supports transforms, report that value in the RRGetCrtcTransform reply. --- hw/xfree86/modes/xf86Crtc.c|6 ++ hw/xfree86/modes/xf86RandR12.c | 25 +

[PATCH] Update RandR global transform when driver notifies of transform change.

Need to compute and save the global transform when the driver changes it. --- randr/rrcrtc.c |9 + 1 files changed, 9 insertions(+), 0 deletions(-) diff --git a/randr/rrcrtc.c b/randr/rrcrtc.c index 1b6350e..c237f03 100644 --- a/randr/rrcrtc.c +++ b/randr/rrcrtc.c @@ -233,6 +233,15

[PATCH] Allow drivers to set crtc transforms.

Track curent transform down in the mode setting code so that it may be set separately from RandR. --- hw/xfree86/modes/xf86Crtc.c| 56 --- hw/xfree86/modes/xf86Crtc.h| 11 +++- hw/xfree86/modes/xf86RandR12.c | 36 +

[PATCH] Be careful about copying transforms around; they have allocated memory.

--- hw/xfree86/modes/xf86Crtc.c |9 ++--- 1 files changed, 6 insertions(+), 3 deletions(-) diff --git a/hw/xfree86/modes/xf86Crtc.c b/hw/xfree86/modes/xf86Crtc.c index 9d13898..e153227 100644 --- a/hw/xfree86/modes/xf86Crtc.c +++ b/hw/xfree86/modes/xf86Crtc.c @@ -271,7 +271,10 @@

Re: [PATCH] When converting from double to fixed, round carefully.

On Fri, 2008-11-14 at 23:31 +0100, Clemens Eisserer wrote: Hi, Perhaps we should extend Render to include 64-bit floating point transforms... That would be really great. I am doing some tricks with mask-transformations having quite a hard time by the fixed-point limitations, especially

Re: X server 1.6 release schedule

On Mon, 2008-11-17 at 13:08 +0100, Matthias Hopf wrote: Keith, AFAICS the standard properties do not inflict any changes on server code except for the naming of the EDID data property, so I assume that's fine here. Yup. I'm unsure whether it would be wise to include panning support in 1.3,

Re: [PATCH] Export a bunch of matrix operations from render.

On Tue, 2008-11-18 at 12:53 +0100, Soeren Sandmann wrote: Can we put these in pixman and add a dependency instead? pixman_transform_point3d is already there; the only reason I left it in the server was for ABI reasons. I'm not sure we want to expose the fixed point versions. -- [EMAIL

Re: [PATCH] Notify DRI when crtc regions change

On Tue, 2008-11-18 at 14:08 -0500, Adam Jackson wrote: I'm not totally convinced that DisableUnusedFunctions is the right place for this to get called, but it's merely overkill. Ack. Yeah, agreed, but DisableUnusedFunctions is the one thing which is always called at the end of any crtc

Re: X server 1.6 release schedule

On Tue, 2008-11-18 at 18:23 -0500, Adam Jackson wrote: Overscan correction? I don't think this counts as a subset of projective transforms, but I could be wrong. No, not a part of projective transforms as it doesn't change the pixel-pixel mapping. It sounds useful; get some code together

Re: X server 1.6 release schedule

On Wed, 2008-11-19 at 10:12 -0500, Adam Jackson wrote: I think it's most natural to do this as additional border fields in a MODEINFO. Imagine a new definition: I'd say adding a new border size and color request would be easier; you'd set the pending border size/color and then set the mode,

Re: X server 1.6 release schedule

On Wed, 2008-11-19 at 13:55 +0100, Éric Piel wrote: Keith Packard schreef: On Tue, 2008-11-18 at 14:42 -0500, Adam Jackson wrote: Hello, Can we define what RANDR 1.3 means? I think we're largely in agreement but I'd like it written down. I think RandR 1.3 includes: 1

[PATCH] Move matrix operations from X server to pixman

Signed-off-by: Keith Packard [EMAIL PROTECTED] --- configure.ac |2 +- pixman/Makefile.am |3 +- pixman/pixman-matrix.c | 594 pixman/pixman-utils.c | 32 --- pixman/pixman.h| 146 5 files changed

X server 1.6_beta1 pending pixman

Søren asked me to move the render matrix operations into pixman, which makes perfect sense. However, that means that X server 1.6 will depend on a pixman with those functions, so I can't release beta1 until pixman is ready to ship with that stuff as well. I don't mind shipping an X server beta

Re: X server 1.6_beta1 pending pixman

On Tue, 2008-11-25 at 17:58 +0100, Soeren Sandmann wrote: Keith Packard [EMAIL PROTECTED] writes: So, we'll see if we can't get a bit of pixman review and perhaps a pixman release done tomorrow so that the X server beta can head out. Here are some comments on the matrix code. I didn't

Re: RandR 1.3 transform protocol numbers

On Wed, 2008-11-26 at 19:14 +0100, Matthias Hopf wrote: randrproto/randr.h: #define X_RRGetScreenResourcesCurrent 25 #define X_RRSetCrtcTransform26 #define X_RRGetCrtcTransform27 xserver/rrdispatch.c: ProcRRSetCrtcTransform, /* 25 */ ProcRRGetCrtcTransform,

Re: [PATCH] randr: add swapped dispatch for RR[GS]etCrtcTransform

On Wed, 2008-11-26 at 22:14 +0100, Julien Cristau wrote: +SwapLongs((CARD32 *)stuff-transform, (sizeof xRenderTransform) 2); +swaps(stuff-nbytesFilter); Please try compiling patches before submitting them. Testing would be a nice bonus too. -- [EMAIL PROTECTED] signature.asc

Re: proto/randrproto: Branch 'master' - 8 commits

On Thu, 2008-11-27 at 15:24 +0100, Julien Cristau wrote: Hi Keith, it seems like the length field in the RRGetCrtcTransform reply should be 24+(pn+pnp)/4+(cn+cnp)/4+pf+cf, not 16+... The reply length doesn't include the first 32 bytes of the reply, so I think 16 is the right value (unless I

Re: [PATCH 12/12] xkb: don't attempt to filter events for devices without key classes.

On Fri, 2008-11-28 at 17:03 +1000, Peter Hutterer wrote: (a huge pile of patches) These all look good to me; can you push them to a branch off of 1.6 so I can merge them in? Oh, the one question I had was about XGE -- I don't see any reason to remove this extension as it seems stable and will

Re: [PATCH 02/13] randrproto: Panning protocol description

On Fri, 2008-11-28 at 18:29 +0100, Matthias Hopf wrote: This looks good to me, I only have a few minor comments about the style, nothing substantial below. Thanks for getting this together. + Note that changes to the screen size might invalidate panning + parameters. In these cases

Re: [PATCH 09/13] xserver: randr: Panning support

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

Re: [PATCH 00/13] RandR 1.3 Panning support

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

Re: [PATCH 12/12] xrandr: Bump version to 1.3.0, RandR requirements to 1.3.0.

On Fri, 2008-11-28 at 17:17 +0100, Matthias Hopf wrote: --- 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

Re: [xserver 1.6] RANDR primary output proposal

On Wed, 2008-12-03 at 13:41 -0500, Adam Jackson wrote: I've pushed a proposal for a pair of requests to get and set the primary output to: http://cgit.freedesktop.org/xorg/proto/randrproto/diff/?h=get-set-primaryid=c25389a1b5cb5cb513eb9486aca4df0d53d089df Please just post diffs here.

Re: [PATCH 02/13] randrproto: Panning protocol description

On Thu, 2008-12-04 at 12:31 +0100, Matthias Hopf wrote: I'd say all of this timestamp stuff can be eliminated. 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

xrandr --panning usage

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

Re: xrandr --panning usage

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

Re: xorg and displayport

On Fri, 2008-12-12 at 14:11 -0500, Dr. Michael J. Chudobiak wrote: Should I be able to get my HP lp2475w monitor to work with DisplayPort on Fedora 10 using the intel driver on a HP DC7900? Nothing seems to work at all... I don't think the DisplayPort is even recognized. For G45/GM45, the

enterleave.c vs the protocol

(btw, thanks so much for the huge comment; I'm going to ignore the code and focus on how the comment relates to the core spec) My theory is that we compute the logical pointer source and destination for each window in the system and deliver events to that window as if the pointer made that

Let the DDX decide on the XkbRulesDefaults.

This patch removes the default rules setting from DIX and adds it to the xfree86 DDX. What happens with other X servers if I apply this patch? -- keith.pack...@intel.com signature.asc Description: This is a digitally signed message part ___ xorg

Re: [RFC] RandR 1.3 properties, version 2

On Thu, 2008-12-18 at 14:41 +0100, Matthias Hopf wrote: I guess I can always add yet another EDID atom string check to my display color profile management code, but is there a reason to change it ? Yeah, adopting a consistent standard property set will help applications in the future as

Re: [PATCHES] improve gamma support for randr-1.2 drivers

On Thu, 2008-12-18 at 17:55 +0100, Matthias Hopf wrote: Keith is the release manager, he will have the last word. CC'ing him. The 1.6 feature set is fixed at this point, so the gamma changes will need to wait for 1.7. -- keith.pack...@intel.com signature.asc Description: This is a digitally

Re: Patch for use of RT_NONE busted by an update to resource.c

On Thu, 2008-12-25 at 01:11 +0100, Julien Cristau wrote: as far as I can tell your patch was never committed. Was this issue fixed somehow, or is this still relevant? I appear to have lost it... -- keith.pack...@intel.com signature.asc Description: This is a digitally signed message part

Re: [PATCH] Don't release passive grabs unless all buttons are up

On Mon, 2009-01-05 at 16:07 +1000, Peter Hutterer wrote: Following up on that: Both the core protocol and the XI protocol spec state that a passive grab is to be released when all buttons are logically up, regardless of modifiers. This is where the magic number 5 comes in. Core allows for 5

Re: [PATCH] Count the number of logically down buttons in buttonsDown

On Mon, 2009-01-05 at 11:59 -0500, Thomas Jaeger wrote: if ((grab-coreGrab !button-state) ... || (!grab-coreGrab AllButtonsAreUp(b)) Unless I'm completely lost, you shouldn't need to make this distinction (see previous message). -- keith.pack...@intel.com signature.asc

Re: Floats in the protocol

On Tue, 2009-01-06 at 13:41 +0100, Simon Thum wrote: On XDS 08, Keith suggested simply putting them on the wire. That is, require IEEE756 32 bit and account for endianness. GLX already uses both 32 and 64 bit IEEE floats on the wire, so I don't see any reason to use something different here.

Re: [intel] 10...@60hz on an intel G45 chipset

On Tue, 2009-01-06 at 15:12 +0100, strawks wrote: My modeline is defined as follow (obtained with cvt -vr 1920 1080 60) : ModeLine 10...@60 173.00 1920 2048 2248 2576 1080 1083 1088 1120 cvt command line parsing is broken -- -vr doesn't emit reduced blanking. Using 'cvt -r 1920 1080': #

Re: Increasing the frame buffer size

On Tue, 2009-01-06 at 08:54 -0800, Dirk Hohndel wrote: So the question is can I increase the size of the framebuffer without restarting X? Or do I have to somehow force a larger virtual display to have enough space prereserved (I tried that in the config file, but a lot of things have

Re: [PATCH 1/5] dix: re-implement enter/leave model.

On Thu, 2009-01-08 at 10:13 +1000, Peter Hutterer wrote: The old model was implemented based on a misunderstanding of NotifyVirtual and NotifyNonlinearVirtual events. It became complicated and was broken in some places [1]. This patch wipes this model completely. Independent of whether this

Re: [PATCH] avoid a potential endless loop.

On Tue, 2009-01-06 at 10:03 +0800, Xiang, Haihao wrote: Previously it is possible that creating rotation data, then cleaning up and creating again so that pScreen-BlockHandler and xf86_config-BlockHandler all point to xf86RotateBlockHandler. Yes, this looks correct to me. So, the race

Should RRGetCrtcInfo return panning bounds?

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. -- keith.pack...@intel.com signature.asc Description: This is a digitally signed message part

Re: Should RRGetCrtcInfo return panning bounds?

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

Proposed server-1.6 enterleave/focusinout patches

I've pushed a proposed set of patches that merge in Peter's new enterleave/focusinout stuff on the 1.6 branch. It's all on the server-1.6-enterleave branch and I'd like comments on whether that code looks right. Mostly what I did was eliminate all of the Device events by #if 0'ing the code. I did

Re: Making the GTK people happy (was: Re: [Fwd: todo items])

On Sat, 2009-01-10 at 13:05 +0200, Daniel Stone wrote: Thanks, Daniel, for capturing and replaying these requests. support for watching for single property changes This is pretty easy; just add the relevant code to XFixes, and the event delivery itself doesn't really change much. If

Re: Should RRGetCrtcInfo return panning bounds?

On Mon, 2009-01-12 at 18:44 +0100, Matthias Hopf wrote: 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. Not currently, as far as I could

Re: Draft XI 2 protocol specification

On Tue, 2009-01-13 at 16:46 +1000, Peter Hutterer wrote: An XDeviceHierarchyChangedEvent is sent whenever the device hierarchy has been changed by either the client, or by server-internal events. The flags specify all types of hierarchy modifiations that have occured. Clients

Re: Draft XI 2 protocol specification

On Tue, 2009-01-13 at 22:37 +1000, Peter Hutterer wrote: The idea here was to be able to filter easily. I expect that many clients won't care much about reattachment, but they would care about new MDs. Having this information may prove useful. As for the deviceids - same idea. I guess this

Re: xf86-video-savage: add missing xf86CrtcConfigInit in SavagePreInit

On Tue, 2009-01-13 at 12:28 -0500, Alex Deucher wrote: These just all happen to be drivers with xrandr 1.2 support. Something changed in the xserver that breaks non xrandr 1.2 drivers. You should probably file a bug (https://bugs.freedesktop.org) and make sure this gets fixed before xserver

Re: 945GM(E) screen rotation and slow GL.

On Wed, 2009-01-14 at 13:18 +0800, Rob Kramer wrote: Cool, thanks. That's a lot better at 18 fps, but still a lot worse than normal landscape operation. Is that expected? I thought with modern GL setups, rotation basically came for free -- but I'm a GL newbie :) The rotation is done by

Re: xf86-video-savage: add missing xf86CrtcConfigInit in SavagePreInit

On Wed, 2009-01-14 at 11:22 +0100, Fabio wrote: Keith Packard wrote: Then fix the driver to support RandR 1.2. The intel driver should also be fixed this way - at least on i810/i815. Yeah, that would require working i810/i815 hardware. In any case, I still don't know if the server patch I

Re: xserver: Branch 'server-1.6-branch' - 2 commits

On Wed, 2009-01-14 at 21:09 -0800, Jeremy Huddleston wrote: Ugg... sorry, I forgot to put it in EXTRA_DIST or whatever it is for the make dist magicness. There's that, and then there's fixing all of the places which use dix-config.h but don't use any other X server includes; they don't know

Re: xserver: Branch 'server-1.6-branch' - 2 commits

On Wed, 2009-01-14 at 23:08 -0800, Jeremy Huddleston wrote: ah ... when builddir != srcdir. Sorry, I always forget that... =/ I'll give that a try... Could we just do something like: dix-config-post.h: $(CP) $(srcdir)/include/dix-config-post.h $(builddir)/include all:

Re: [ANNOUNCE] xf86-video-intel 2.5.99.2

On Fri, 2009-01-16 at 09:56 +0200, Vasily Khoruzhick wrote: I've just tried xf86-video-2.6.0, xorg-server-1.5.99.901 and mesa-7.3_rc2, still got artefacts with uxa (same as on http://fenix-fen.at.tut.by/screen-3.png) and xserver hangs (and no way to stop it except restarting whole system)

Re: With xorg intel driver, is it possible to bypass DDC and use a higher resolution?

On Sun, 2009-01-18 at 11:00 +0800, Zhe Su wrote: Hi, I just bought a machine with Intel DG45ID mother board. I installed openSUSE 11.1 and use the on-board graphics card to connect my 37' Full HD LCD TV via a HDMI cable. However the highest resolution can be used is 1600x1200 instead of

  1   2   3   >