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 work in progress, mostly the introductory/background sections though. The requests and wire encoding sections are mostly complete and is close to what's in the git repos at this point. The implementation isn't fully uptodate with the spec yet, but I figured it would be wise to circulate the spec before doing more code churn, so here it is. You probably don't need the sub-pixel ordering stuff :-) Do you want a request to list the available DRI2 types? I don't think we want the window position in the GetBuffers request, that makes the buffers 'obviously' independent of position. Oh, and some checking to make sure the remaining 'randr' wording is cleaned up. It would also be nice to see some additional description about how this works with GEM. -- [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: 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 existing authentication protocol. What we want is a way to let applications identify themselves with the kernel and 'prove' that they have permission to access kernel objects. It seems like having the X server return a 'cookie' that the client could use with the kernel module might make things simpler: ┌─── DRI2Connect window: WINDOW type: STRING ▶ driver: STRING device: STRING -- device file name auth-data: LISTofCARD8 └─── 'auth-data' is an arbitrary array of bytes which the client passes to the direct rendering system to validate the client's access of direct rendering objects created by the X server. It seems like this offers precisely the right guarantee -- the client proves to the kernel that it is connected to the X server and thus should be granted permission to access the X server objects. Under some tighter access control mechanisms, the 'auth-data' could even be generated per-client so that the client would only have access to a sub-set of X server objects. I do wonder if DRI2GetBuffers should return the drawable position relative to the origin of each buffer... guess it isn't strictly necessary except maybe for the real frontbuffer. One of the requirements in DRI2 is that the 'real' front buffer be invisible to applications; there's no way the application can sensibly use those contents. Moreover, the drawable position may change without any warning due to window configuration. For DRI2CopyRegion, you're leaving it to the DDX driver to pick the CRTC to synchronize to? I'm not sure that'll work too well with overlapping viewports, where the user may want to choose which CRTC to synchronize to for each application. Yeah, I don't see a good way to avoid this, and the client can always pass in 'Automatic' (0) and let the server pick the 'right' one. This request also still seems to be missing return values for the sequence number when the copy is expected to take place and tokens for synchronization of direct rendering to the source/destination buffer. Eliminating the reply avoids a round trip, so I'm in favor of not providing any if it's not strictly necessary. I don't know if the GL api requires us to provide the expected sequence number back to the application. For synchronization, we should expect the kernel module to perform this automatically -- once the X server has processed this request, the kernel can pend further rendering to the source buffer until the copy has finished. That would, of course, require that the application know that the kernel has received the copy command from the X server -- so the client would need to get something from X server indicating that it had finished processing the Copy request. The easiest thing to use would be a reply, but we'd structure the library so that the client wouldn't pend on the reply and could block just before touching the back buffer again. Note that there isn't any synchronization on the real front buffer; that isn't a legal target for direct rendering. Oh, and I think it should take relative sequence numbers as well as absolute ones. Yeah, GL does kinda require this. -- [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: 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 available set of buffers as well. Yeah. Though, I imagine the GEM interaction text will be implementation notes/suggestion type of stuff, we want the DRI2 spec to be DRM and GEM independent. I'll try to spell out the requirements DRI2 has on the underlying system (essentially, the ability to name buffers by a 32 bit integer and share them and the auth mechanism). Having notes about how this works with GEM would be useful, although it should be a separate appendix. -- [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: 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 server you're authenticated. What better way to establish that than, erh, passing it through protocol? The key point is that the server does the ioctl that authenticates the client. Ok, so the kernel generates a unique token that identifies the client which the client takes and hands to the X server to pass back into the kernel to authorize the client. Just trying to figure out how this stuff is supposed to work. -- [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: 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 a bit harder. -- [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: 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 systems would often just discard all window contents on resize. Adding well-defined bit and window gravity to X11 made it able to preserve window contents across resize in a predictable manner, and the whole adventure in SlideAndSizeWindow was designed to 'fix' what was once a fairly broken implementation of that. The recomputation of exposures is a fairly blunt instrument to apply in this case, but it was the easiest mechanism I could come up with at the time. -- [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: 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 isn't a good idea as any bugs in that will likely go unfixed for years. Is there some specific system which doesn't have any library providing a SHA1 implementation? I've reverted this patch; you're welcome to create a patch which uses an external SHA1 library of your own making, but I don't want X.org to be in the position of maintaining this code. -- [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
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 targeted for Xserver 1.6, so I'd like to get the spec nailed
down and the implementation finished in the next couple of weeks if
possible; it seems like a simple thing to me.
So, I'll start with a guess and hope that people who actually know what
gnome (and even other desktops) want and can push us in the right
direction.
CRTCCONFIG { id: CRTC
width, height: CARD16
x, y: INT16
transform: TRANSFORM
}
OUTPUTCONFIG { id: OUTPUT
crtc: CRTC
width_in_mm, height_in_mm: CARD16
}
┌───
RRGetScreenConfiguration
window: WINDOW
▶
crtc-configs: LISTofCRTCCONFIG
output-configs: LISTofOUTPUTCONFIG
└───
Errors: Window
This request returns the current configuration of the crtcs and outputs
for the screen associated with 'window'. This allows applications to
discover the complete geometry of the system in a single request, and
without asking for any external hardware status changes. 'transform'
contains the combination of any assigned projective transformation and
rotation/reflection set by the client.
--
[EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [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 modifies only one of the two pointers (head and tail). There shouldn't be any need to have a mutex which protects both of these values together, and doing so prevents mouse motion while the server is processing events. Is there something fundamentally different between threaded input and SIGIO- or kernel-based input that I'm missing here? -- [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [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 SMP visibility, isn't it a tiny bit risky to have 3 'independent' miEventQueue.head reads in miEnqueue? Given the old 'SIGIO' based code, it didn't matter. Even now, it doesn't really matter as in the worst case we fail to store an event when the queue is nearly full but the server is processing events. (b) may suffice. Locking the queue in OsBlockSigs() should do it and fix most miEnqueue users. Or just lock the queue in mieqEnqueue itself; keeping the lock near the code seems like a lot better plan to me. -- [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [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 the queue in mieqEnqueue itself; keeping the lock near the code seems like a lot better plan to me. Except if the lock is held across the entire event processing, because we need to queue events from event processing. That makes it more important that the mutex cover precisely the values which will be modified in multiple threads, inserting events into the queue, and not pulling them out, which is done only in a single thread. -- [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: 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 Halasa for their basic PIPEACONF investigations posted here: I845 and earlier chips (I didn't look at the i855 or i865) do not support interlaced display at all. -- [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: 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 display support. OK, but if there is an 'interlace gap' between and including i830 - i865 then I will stop to find a solution for this issue. Yup, I read through the hardware docs for i845 and compared them with i945 -- all of the places where the i945 says 'for interlaced modes, do foo' just don't exist in the i845 docs. Btw, let us know when you're happy with the interlaced mode support and we'll stick it into the upstream driver sources. Not that we like to encourage people to use interlaced modes, but there are times when it's the only option. -- [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [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 signals are blocked while that handler is running. -- [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: 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 that ABI numbers between two released servers reflect changes in the ABI that have occurred between those releases. For unreleased servers, we shouldn't make any guarantees. However, if you want to bump the number more often than each release, that's fine with me. -- [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: 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 at the top of our list. You shouldn't need a new kernel or new X server. -- [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: 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 either, I'd say we're reasonably justified in just making this a Match error. -- [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: 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 glxgears should be wired to the refresh rate. -- [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: 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, I shouldn't have assumed that '70-75' was a variable number :-) -- [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: 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 the same code base for their hardware. Forking driver development is a great way to explore new ideas and demonstrate new technologies, but in the long-term, we really want the best ideas to be integrated into a single driver for each device. Fortunately, X.org doesn't control what anyone uses on their own machines, so people remain free to ignore what X.org ships and replace any or all of it with other software. -keith signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [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: http://git.kernel.org/?p=linux/kernel/git/anholt/drm-intel.git;a=commit;h=2052746fc8397130c120f0194a89938b0b62b6cb -- [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: 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 message, we would have fixed it, but it's the old kernel driver. That old driver could be patched to not print the message. -- [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[PATCH] Notify DRI when crtc regions change
Drivers that care about crtc positions on the screen to ensure that
vblank works correctly need to be notified when crtcs are changed. Provide a
dri-specific hook in the mode setting code that is invoked whenever any
configuration is done to the screen so that DRI clients are notified and
receive 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, 24 insertions(+), 0 deletions(-)
diff --git a/hw/xfree86/dri/Makefile.am b/hw/xfree86/dri/Makefile.am
index e17cea7..3ec30be 100644
--- a/hw/xfree86/dri/Makefile.am
+++ b/hw/xfree86/dri/Makefile.am
@@ -1,6 +1,11 @@
libdri_la_LTLIBRARIES = libdri.la
libdri_la_CFLAGS = -I$(top_srcdir)/hw/xfree86/common \
-I$(top_srcdir)/hw/xfree86/os-support \
+ -I$(top_srcdir)/hw/xfree86/modes \
+ -I$(top_srcdir)/hw/xfree86/ddc \
+ -I$(top_srcdir)/hw/xfree86/i2c \
+ -I$(top_srcdir)/hw/xfree86/parser \
+ -I$(top_srcdir)/hw/xfree86/ramdac \
-I$(top_srcdir)/hw/xfree86/os-support/bus \
-I$(top_srcdir)/glx \
-I$(top_srcdir)/GL/include \
diff --git a/hw/xfree86/dri/dri.c b/hw/xfree86/dri/dri.c
index 3713659..13468dd 100644
--- a/hw/xfree86/dri/dri.c
+++ b/hw/xfree86/dri/dri.c
@@ -71,6 +71,7 @@ SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
#include mipointer.h
#include xf86_OSproc.h
#include inputstr.h
+#include xf86Crtc.h
#define PCI_BUS_NO_DOMAIN(bus) ((bus) 0xffu)
@@ -302,6 +303,8 @@ DRIOpenDRMMaster(ScrnInfoPtr pScrn,
return FALSE;
}
+static void
+DRIClipNotifyAllDrawables(ScreenPtr pScreen);
Bool
DRIScreenInit(ScreenPtr pScreen, DRIInfoPtr pDRIInfo, int *pDRMFD)
@@ -579,6 +582,8 @@ DRIScreenInit(ScreenPtr pScreen, DRIInfoPtr pDRIInfo, int
*pDRMFD)
break;
}
+xf86_set_dri_crtc_notify_hook(DRIClipNotifyAllDrawables);
+
return TRUE;
}
diff --git a/hw/xfree86/loader/xf86sym.c b/hw/xfree86/loader/xf86sym.c
index 4891be2..7569fd6 100644
--- a/hw/xfree86/loader/xf86sym.c
+++ b/hw/xfree86/loader/xf86sym.c
@@ -914,6 +914,7 @@ _X_HIDDEN void *xfree86LookupTab[] = {
SYMFUNC(xf86_hide_cursors)
SYMFUNC(xf86_cursors_fini)
SYMFUNC(xf86_crtc_clip_video_helper)
+SYMFUNC(xf86_set_dri_crtc_notify_hook)
SYMFUNC(xf86DoEDID_DDC1)
SYMFUNC(xf86DoEDID_DDC2)
diff --git a/hw/xfree86/modes/xf86Crtc.c b/hw/xfree86/modes/xf86Crtc.c
index df47598..0ae1e4d 100644
--- a/hw/xfree86/modes/xf86Crtc.c
+++ b/hw/xfree86/modes/xf86Crtc.c
@@ -2545,6 +2545,14 @@ xf86SaveScreen(ScreenPtr pScreen, int mode)
return TRUE;
}
+static void (*dri_crtc_notify_hook) (ScreenPtr pScreen);
+
+_X_EXPORT void
+xf86_set_dri_crtc_notify_hook (void (*hook) (ScreenPtr pScreen))
+{
+dri_crtc_notify_hook = hook;
+}
+
/**
* Disable all inactive crtcs and outputs
*/
@@ -2571,6 +2579,8 @@ xf86DisableUnusedFunctions(ScrnInfoPtr pScrn)
memset(crtc-mode, 0, sizeof(crtc-mode));
}
}
+if (dri_crtc_notify_hook pScrn-pScreen)
+ dri_crtc_notify_hook (pScrn-pScreen);
}
#ifdef RANDR_12_INTERFACE
diff --git a/hw/xfree86/modes/xf86Crtc.h b/hw/xfree86/modes/xf86Crtc.h
index 83b1f13..0ed6768 100644
--- a/hw/xfree86/modes/xf86Crtc.h
+++ b/hw/xfree86/modes/xf86Crtc.h
@@ -722,6 +722,9 @@ Bool
xf86SaveScreen(ScreenPtr pScreen, int mode);
void
+xf86_set_dri_crtc_notify_hook (void (*hook) (ScreenPtr pScreen));
+
+void
xf86DisableUnusedFunctions(ScrnInfoPtr pScrn);
DisplayModePtr
--
1.5.6.5
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
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, but just changing crtcs around without changing the size would not. If we wanted a standard macro set I wouldn't complain. I'm loathe to introduce more function calls to the standard wrap chains though, O(n) devprivates was a bad enough performance hit to make me hesitant to introduce more things that grow linearly with number of subsystems. Yeah. I'll just expose the structure and get DRI to wrap it in the usual way. -- [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: 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
versions.
I also tried kernel versions 2.6.27.3, 2.6.27.5, 2.6.28-rc3 but it
seems like it doesnt make a difference.
Im using a Thinkpad X200, which includes the Intel GMA X4500MHD.
I posted a patch to save/restore MCHBAR_RENDER_STANDBY which made my
X200s happy. Let us know if this helps for you.
--
[EMAIL PROTECTED]
0001--drm-i915-Save-restore-MCHBAR_RENDER_STANDBY-on-GM9.patch
Description: application/mbox
signature.asc
Description: This is a digitally signed message part
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
[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..c785c45 100644
--- a/hw/xfree86/common/xf86Xinput.c
+++ b/hw/xfree86/common/xf86Xinput.c
@@ -130,16 +130,16 @@ ProcessVelocityConfiguration(char* devname, pointer list,
DeviceVelocityPtr s){
xf86Msg(X_CONFIG, %s: (accel) filter stage %i: %.2f ms\n,
devname, i, 1.0f / (s-filters[i].rdecay));
-tempf = xf86SetIntOption(list, ConstantDeceleration, 1);
-if(tempf 1.0){
+tempf = xf86SetRealOption(list, ConstantDeceleration, 1.0);
+if(tempf != 1.0){
xf86Msg(X_CONFIG, %s: (accel) constant deceleration by %.1f\n,
devname, tempf);
s-const_acceleration = 1.0 / tempf; /* set reciprocal deceleration
alias acceleration */
}
-tempf = xf86SetIntOption(list, AdaptiveDeceleration, 1);
-if(tempf 1.0){
+tempf = xf86SetRealOption(list, AdaptiveDeceleration, 1.0);
+if(tempf != 1.0){
xf86Msg(X_CONFIG, %s: (accel) adaptive deceleration by %.1f\n,
devname, tempf);
s-min_acceleration = 1.0 / tempf; /* set minimum acceleration */
--
1.5.6.5
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
[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 = xyes; then - XNEST_LIBS=$FB_LIB $FIXES_LIB $MI_LIB $XEXT_LIB $DBE_LIB $RECORD_LIB $GLX_LIBS $RENDER_LIB $RANDR_LIB $DAMAGE_LIB $MIEXT_DAMAGE_LIB $MIEXT_SHADOW_LIB $XI_LIB $XKB_LIB $XKB_STUB_LIB $COMPOSITE_LIB $DIX_LIB $OS_LIB $CONFIG_LIB + XNEST_LIBS=$FB_LIB $FIXES_LIB $MI_LIB $XEXT_LIB $DBE_LIB $RECORD_LIB $GLX_LIBS $RANDR_LIB $RENDER_LIB $DAMAGE_LIB $MIEXT_DAMAGE_LIB $MIEXT_SHADOW_LIB $XI_LIB $XKB_LIB $XKB_STUB_LIB $COMPOSITE_LIB $DIX_LIB $OS_LIB $CONFIG_LIB XNEST_SYS_LIBS=$XNESTMODULES_LIBS $GLX_SYS_LIBS AC_SUBST([XNEST_LIBS]) AC_SUBST([XNEST_SYS_LIBS]) -- 1.5.6.5 ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[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 @@ PictureTransformTranslate (PictTransformPtr forward,
PictureTransformInitTranslate (t, tx, ty);
if (!PictureTransformMultiply (forward, t, forward))
return FALSE;
-
+
PictureTransformInitTranslate (t, -tx, -ty);
if (!PictureTransformMultiply (reverse, reverse, t))
return FALSE;
@@ -349,3 +349,37 @@ PictureTransformIsInverse (PictTransform *a, PictTransform
*b)
return PictureTransformIsIdentity (t);
}
+_X_EXPORT void
+PictTransform_from_xRenderTransform (PictTransformPtr pict,
+xRenderTransform *render)
+{
+pict-matrix[0][0] = render-matrix11;
+pict-matrix[0][1] = render-matrix12;
+pict-matrix[0][2] = render-matrix13;
+
+pict-matrix[1][0] = render-matrix21;
+pict-matrix[1][1] = render-matrix22;
+pict-matrix[1][2] = render-matrix23;
+
+pict-matrix[2][0] = render-matrix31;
+pict-matrix[2][1] = render-matrix32;
+pict-matrix[2][2] = render-matrix33;
+}
+
+void
+xRenderTransform_from_PictTransform (xRenderTransform *render,
+PictTransformPtr pict)
+{
+render-matrix11 = pict-matrix[0][0];
+render-matrix12 = pict-matrix[0][1];
+render-matrix13 = pict-matrix[0][2];
+
+render-matrix21 = pict-matrix[1][0];
+render-matrix22 = pict-matrix[1][1];
+render-matrix23 = pict-matrix[1][2];
+
+render-matrix31 = pict-matrix[2][0];
+render-matrix32 = pict-matrix[2][1];
+render-matrix33 = pict-matrix[2][2];
+}
+
diff --git a/render/picturestr.h b/render/picturestr.h
index f7a0664..93d86bd 100644
--- a/render/picturestr.h
+++ b/render/picturestr.h
@@ -720,12 +720,17 @@ Bool
PictureTransformIsScale(PictTransform *t);
Bool
-PictureTransformIsScale(PictTransform *t);
-
-Bool
PictureTransformIsTranslate (PictTransform *t);
Bool
PictureTransformIsInverse(PictTransform *t, PictTransform *i);
+void
+PictTransform_from_xRenderTransform (PictTransformPtr pict,
+xRenderTransform *render);
+
+void
+xRenderTransform_from_PictTransform (xRenderTransform *render,
+PictTransformPtr pict);
+
#endif /* _PICTURESTR_H_ */
--
1.5.6.5
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
[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 +++---
render/picturestr.h |9 ++-
2 files changed, 47 insertions(+), 19 deletions(-)
diff --git a/render/filter.c b/render/filter.c
index aa3eb1a..e499fc4 100644
--- a/render/filter.c
+++ b/render/filter.c
@@ -213,7 +213,7 @@ PictureFindFilter (ScreenPtr pScreen, char *name, int len)
}
static Bool
-convolutionFilterValidateParams (PicturePtr pPicture,
+convolutionFilterValidateParams (ScreenPtr pScreen,
int filter,
xFixed *params,
int nparams)
@@ -270,29 +270,51 @@ int
SetPictureFilter (PicturePtr pPicture, char *name, int len, xFixed *params,
int nparams)
{
PictFilterPtr pFilter;
-xFixed *new_params;
-inti, s, result;
+ScreenPtr pScreen;
-pFilter = PictureFindFilter (screenInfo.screens[0], name, len);
+if (pPicture-pDrawable != NULL)
+ pScreen = pPicture-pDrawable-pScreen;
+else
+ pScreen = screenInfo.screens[0];
+
+pFilter = PictureFindFilter (pScreen, name, len);
+
+if (!pFilter)
+ return BadName;
-if (pPicture-pDrawable == NULL) {
+if (pPicture-pDrawable == NULL)
+{
+ int s;
/* For source pictures, the picture isn't tied to a screen. So, ensure
* that all screens can handle a filter we set for the picture.
*/
- for (s = 0; s screenInfo.numScreens; s++) {
- if (PictureFindFilter (screenInfo.screens[s], name, len)-id !=
- pFilter-id)
- {
+ for (s = 1; s screenInfo.numScreens; s++)
+ {
+ PictFilterPtr pScreenFilter;
+ pScreenFilter = PictureFindFilter (screenInfo.screens[s],
+ name, len);
+ if (!pScreenFilter || pScreenFilter-id != pFilter-id)
return BadMatch;
- }
}
}
+return SetPicturePictFilter (pPicture, pFilter, params, nparams);
+}
+
+int
+SetPicturePictFilter (PicturePtr pPicture, PictFilterPtr pFilter,
+ xFixed *params, int nparams)
+{
+ScreenPtr pScreen;
+inti;
+
+if (pPicture-pDrawable)
+ pScreen = pPicture-pDrawable-pScreen;
+else
+ pScreen = screenInfo.screens[0];
-if (!pFilter)
- return BadName;
if (pFilter-ValidateParams)
{
- if (!(*pFilter-ValidateParams) (pPicture, pFilter-id, params,
nparams))
+ if (!(*pFilter-ValidateParams) (pScreen, pFilter-id, params, nparams))
return BadMatch;
}
else if (nparams)
@@ -300,7 +322,7 @@ SetPictureFilter (PicturePtr pPicture, char *name, int len,
xFixed *params, int
if (nparams != pPicture-filter_nparams)
{
- new_params = xalloc (nparams * sizeof (xFixed));
+ xFixed *new_params = xalloc (nparams * sizeof (xFixed));
if (!new_params nparams)
return BadAlloc;
xfree (pPicture-filter_params);
@@ -311,9 +333,10 @@ SetPictureFilter (PicturePtr pPicture, char *name, int
len, xFixed *params, int
pPicture-filter_params[i] = params[i];
pPicture-filter = pFilter-id;
-if (pPicture-pDrawable) {
- ScreenPtr pScreen = pPicture-pDrawable-pScreen;
- PictureScreenPtr ps = GetPictureScreen(pScreen);
+if (pPicture-pDrawable)
+{
+ PictureScreenPtrps = GetPictureScreen(pScreen);
+ int result;
result = (*ps-ChangePictureFilter) (pPicture, pPicture-filter,
params, nparams);
diff --git a/render/picturestr.h b/render/picturestr.h
index 93d86bd..8a926ce 100644
--- a/render/picturestr.h
+++ b/render/picturestr.h
@@ -184,7 +184,7 @@ typedef struct _Picture {
SourcePictPtr pSourcePict;
} PictureRec;
-typedef Bool (*PictFilterValidateParamsProcPtr) (PicturePtr pPicture, int id,
+typedef Bool (*PictFilterValidateParamsProcPtr) (ScreenPtr pScreen, int id,
xFixed *params, int nparams);
typedef struct {
char *name;
@@ -473,7 +473,12 @@ PictFilterPtr
PictureFindFilter (ScreenPtr pScreen, char *name, int len);
int
-SetPictureFilter (PicturePtr pPicture, char *name, int len, xFixed *params,
int nparams);
+SetPicturePictFilter (PicturePtr pPicture, PictFilterPtr pFilter,
+ xFixed *params, int nparams);
+
+int
+SetPictureFilter (PicturePtr pPicture, char *name, int len,
+ xFixed *params, int nparams);
Bool
PictureFinishInit (void);
--
1.5.6.5
___
xorg
[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 +37,7 @@
#include xf86Crtc.h
#include xf86Modes.h
#include xf86RandR12.h
+#include xf86CursorPriv.h
#include X11/extensions/render.h
#define DPMS_SERVER
#include X11/extensions/dpms.h
@@ -321,10 +322,18 @@ xf86_crtc_set_cursor_position (xf86CrtcPtr crtc, int x,
int y)
*/
if (crtc-transform_in_use)
{
+ ScreenPtr screen = scrn-pScreen;
+ xf86CursorScreenPtr ScreenPriv =
+ (xf86CursorScreenPtr)dixLookupPrivate(screen-devPrivates,
+ xf86CursorScreenKey);
PictVector v;
+ x += ScreenPriv-HotX;
+ y += ScreenPriv-HotY;
v.vector[0] = IntToxFixed (x); v.vector[1] = IntToxFixed (y);
v.vector[2] = IntToxFixed(1);
PictureTransformPoint (crtc-framebuffer_to_crtc, v);
x = xFixedToInt (v.vector[0]); y = xFixedToInt (v.vector[1]);
+ x -= ScreenPriv-HotX;
+ y -= ScreenPriv-HotY;
}
else
{
--
1.5.6.5
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
[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 deletions(-)
diff --git a/randr/rrcrtc.c b/randr/rrcrtc.c
index b715884..b8b9ec0 100644
--- a/randr/rrcrtc.c
+++ b/randr/rrcrtc.c
@@ -608,8 +608,6 @@ RRCrtcTransformSet (RRCrtcPtr crtc,
PictFilterPtr filter = NULL;
intwidth = 0, height = 0;
-if (!PictureTransformIsInverse (transform, inverse))
- return BadMatch;
if (filter_len)
{
filter = PictureFindFilter (crtc-pScreen,
@@ -1229,7 +1227,8 @@ ProcRRSetCrtcTransform (ClientPtr client)
return RRErrorBase + BadRRCrtc;
PictTransform_from_xRenderTransform (transform, stuff-transform);
-PictTransform_from_xRenderTransform (inverse, stuff-inverse);
+if (!PictureTransformInvert (inverse, transform))
+ return BadMatch;
filter = (char *) (stuff + 1);
nbytes = stuff-nbytesFilter;
--
1.5.6.5
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
[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 b/hw/xfree86/modes/xf86Rotate.c
index dc9ad11..7b49afa 100644
--- a/hw/xfree86/modes/xf86Rotate.c
+++ b/hw/xfree86/modes/xf86Rotate.c
@@ -154,6 +154,35 @@ xf86CrtcDamageShadow (xf86CrtcPtr crtc)
}
static void
+xf86CrtcShadowClear (xf86CrtcPtr crtc)
+{
+PixmapPtr dst_pixmap = crtc-rotatedPixmap;
+ScrnInfoPtrscrn = crtc-scrn;
+ScreenPtr screen = scrn-pScreen;
+PicturePtr dst;
+PictFormatPtr format = compWindowFormat (WindowTable[screen-myNum]);
+static xRenderColor black = { 0, 0, 0, 0 };
+xRectangle rect;
+interror;
+
+dst = CreatePicture (None,
+dst_pixmap-drawable,
+format,
+0L,
+NULL,
+serverClient,
+error);
+if (!dst)
+ return;
+rect.x = 0;
+rect.y = 0;
+rect.width = dst_pixmap-drawable.width;
+rect.height = dst_pixmap-drawable.height;
+CompositeRects (PictOpSrc, dst, black, 1, rect);
+FreePicture (dst, None);
+}
+
+static void
xf86RotatePrepare (ScreenPtr pScreen)
{
ScrnInfoPtrpScrn = xf86Screens[pScreen-myNum];
@@ -170,6 +199,7 @@ xf86RotatePrepare (ScreenPtr pScreen)
crtc-rotatedData,
crtc-mode.HDisplay,
crtc-mode.VDisplay);
+ xf86CrtcShadowClear (crtc);
if (!xf86_config-rotation_damage_registered)
{
/* Hook damage to screen pixmap */
--
1.5.6.5
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
[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 100644 --- a/randr/rrcrtc.c +++ b/randr/rrcrtc.c @@ -1341,14 +1341,12 @@ ProcRRGetCrtcTransform (ClientPtr client) reply-hasTransforms = crtc-transforms; transform_encode (client, reply-pendingTransform, pending-transform); -transform_encode (client, reply-pendingInverse, pending-inverse); extra += transform_filter_encode (client, extra, reply-pendingNbytesFilter, reply-pendingNparamsFilter, pending); transform_encode (client, reply-currentTransform, current-transform); -transform_encode (client, reply-currentInverse, current-inverse); extra += transform_filter_encode (client, extra, reply-currentNbytesFilter, reply-currentNparamsFilter, -- 1.5.6.5 ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[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 +---
randr/randrstr.h | 45 +
randr/rrcrtc.c | 203 +-
randr/rrdispatch.c |5 +-
randr/rrsdispatch.c| 23 +
7 files changed, 283 insertions(+), 212 deletions(-)
diff --git a/hw/xfree86/modes/xf86Crtc.c b/hw/xfree86/modes/xf86Crtc.c
index 0ba0477..a40bf18 100644
--- a/hw/xfree86/modes/xf86Crtc.c
+++ b/hw/xfree86/modes/xf86Crtc.c
@@ -351,6 +351,10 @@ xf86CrtcSetMode (xf86CrtcPtr crtc, DisplayModePtr mode,
Rotation rotation,
#endif
}
}
+#ifdef RANDR_12_INTERFACE
+if (crtc-randr_crtc)
+ RRCrtcPostPendingTransform (crtc-randr_crtc);
+#endif
/* XXX free adjustedmode */
ret = TRUE;
diff --git a/hw/xfree86/modes/xf86RandR12.c b/hw/xfree86/modes/xf86RandR12.c
index 2ae8ea7..6e14bd7 100644
--- a/hw/xfree86/modes/xf86RandR12.c
+++ b/hw/xfree86/modes/xf86RandR12.c
@@ -755,6 +755,9 @@ xf86RandR12CrtcSet (ScreenPtr pScreen,
if (rotation != crtc-rotation)
changed = TRUE;
+if (RRCrtcPendingTransform (randr_crtc))
+ changed = TRUE;
+
if (x != crtc-x || y != crtc-y)
changed = TRUE;
for (o = 0; o config-num_output; o++)
diff --git a/hw/xfree86/modes/xf86Rotate.c b/hw/xfree86/modes/xf86Rotate.c
index 5ab2bf8..7967e5b 100644
--- a/hw/xfree86/modes/xf86Rotate.c
+++ b/hw/xfree86/modes/xf86Rotate.c
@@ -70,205 +70,9 @@ compWindowFormat (WindowPtr pWin)
#define F(x) IntToxFixed(x)
-static void
-PictureTransformIdentity (PictTransformPtr matrix)
-{
-inti;
-memset (matrix, '\0', sizeof (PictTransform));
-for (i = 0; i 3; i++)
- matrix-matrix[i][i] = F(1);
-}
-
-static Bool
-PictureTransformMultiply (PictTransformPtr dst, PictTransformPtr l,
PictTransformPtr r)
-{
-PictTransform d;
-intdx, dy;
-into;
-
-for (dy = 0; dy 3; dy++)
- for (dx = 0; dx 3; dx++)
- {
- xFixed_48_16v;
- xFixed_32_32partial;
- v = 0;
- for (o = 0; o 3; o++)
- {
- partial = (xFixed_32_32) l-matrix[dy][o] * (xFixed_32_32)
r-matrix[o][dx];
- v += partial 16;
- }
- if (v MAX_FIXED_48_16 || v MIN_FIXED_48_16)
- return FALSE;
- d.matrix[dy][dx] = (xFixed) v;
- }
-*dst = d;
-return TRUE;
-}
-
-static void
-PictureTransformInitScale (PictTransformPtr t, xFixed sx, xFixed sy)
-{
-memset (t, '\0', sizeof (PictTransform));
-t-matrix[0][0] = sx;
-t-matrix[1][1] = sy;
-t-matrix[2][2] = F (1);
-}
-
-static xFixed
-fixed_inverse (xFixed x)
-{
-return (xFixed) xFixed_48_16) F(1)) * F(1)) / x);
-}
-
-static Bool
-PictureTransformScale (PictTransformPtr forward,
- PictTransformPtr reverse,
- xFixed sx, xFixed sy)
-{
-PictTransform t;
-
-PictureTransformInitScale (t, sx, sy);
-if (!PictureTransformMultiply (forward, t, forward))
- return FALSE;
-PictureTransformInitScale (t, fixed_inverse (sx), fixed_inverse (sy));
-if (!PictureTransformMultiply (reverse, reverse, t))
- return FALSE;
-return TRUE;
-}
-
-static void
-PictureTransformInitRotate (PictTransformPtr t, xFixed c, xFixed s)
-{
-memset (t, '\0', sizeof (PictTransform));
-t-matrix[0][0] = c;
-t-matrix[0][1] = -s;
-t-matrix[1][0] = s;
-t-matrix[1][1] = c;
-t-matrix[2][2] = F (1);
-}
-
-static Bool
-PictureTransformRotate (PictTransformPtr forward,
- PictTransformPtr reverse,
- xFixed c, xFixed s)
-{
-PictTransform t;
-PictureTransformInitRotate (t, c, s);
-if (!PictureTransformMultiply (forward, t, forward))
- return FALSE;
-
-PictureTransformInitRotate (t, c, -s);
-if (!PictureTransformMultiply (reverse, reverse, t))
- return FALSE;
-return TRUE;
-}
-
-static void
-PictureTransformInitTranslate (PictTransformPtr t, xFixed tx, xFixed ty)
-{
-memset (t, '\0', sizeof (PictTransform));
-t-matrix[0][0] = F (1);
-t-matrix[0][2] = tx;
-t-matrix[1][1] = F (1);
-t-matrix[1][2] = ty;
-t-matrix[2][2] = F (1);
-}
-
-static Bool
-PictureTransformTranslate (PictTransformPtr forward,
- PictTransformPtr reverse,
- xFixed tx, xFixed ty)
-{
-PictTransform t;
-PictureTransformInitTranslate (t, tx, ty);
-if (!PictureTransformMultiply (forward, t, forward))
- return FALSE;
-
-PictureTransformInitTranslate (t, -tx, -ty);
-if (!PictureTransformMultiply (reverse, reverse, t))
- return FALSE;
-
[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 c237f03..c431637 100644
--- a/randr/rrcrtc.c
+++ b/randr/rrcrtc.c
@@ -233,7 +233,7 @@ RRCrtcNotify (RRCrtcPtr crtc,
RRTransformCopy (crtc-client_current_transform, transform);
RRCrtcChanged (crtc, TRUE);
}
-if (crtc-changed)
+if (crtc-changed mode)
{
RRTransformCompute (x, y,
mode-mode.width, mode-mode.height,
--
1.5.6.5
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
[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 a/hw/xfree86/modes/xf86Cursors.c b/hw/xfree86/modes/xf86Cursors.c
index 4065789..cd4f9e8 100644
--- a/hw/xfree86/modes/xf86Cursors.c
+++ b/hw/xfree86/modes/xf86Cursors.c
@@ -330,23 +330,23 @@ xf86_crtc_set_cursor_position (xf86CrtcPtr crtc, int x,
int y)
v.v[0] = x + ScreenPriv-HotX; v.v[1] = y + ScreenPriv-HotY; v.v[2] =
1;
pict_f_transform_point (crtc-f_framebuffer_to_crtc, v);
- x = floor (v.v[0] + 0.5) - ScreenPriv-HotX;
- y = floor (v.v[1] + 0.5) - ScreenPriv-HotY;
+ x = floor (v.v[0] + 0.5);
+ y = floor (v.v[1] + 0.5);
+ /*
+* Transform position of cursor upper left corner
+*/
+ xf86_crtc_rotate_coord_back (crtc-rotation,
+cursor_info-MaxWidth,
+cursor_info-MaxHeight,
+ScreenPriv-HotX, ScreenPriv-HotY, dx,
dy);
+ x -= dx;
+ y -= dy;
}
else
{
x -= crtc-x;
y -= crtc-y;
}
-/*
- * Transform position of cursor upper left corner
- */
-xf86_crtc_rotate_coord_back (crtc-rotation,
-cursor_info-MaxWidth,
-cursor_info-MaxHeight,
-0, 0, dx, dy);
-x -= dx;
-y -= dy;
/*
* Disable the cursor when it is outside the viewport
--
1.5.6.5
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
[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 #include rrtransform.h void -- 1.5.6.5 ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[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 the fixed point matrix comes along for the ride everywhere.
---
hw/xfree86/modes/xf86Crtc.c|3 +-
hw/xfree86/modes/xf86Crtc.h|3 +-
hw/xfree86/modes/xf86Cursors.c | 16 +-
hw/xfree86/modes/xf86Rotate.c | 167 +++--
randr/randrstr.h | 27 ++--
randr/rrcrtc.c | 136 --
render/matrix.c| 324 +++-
render/picturestr.h| 63
8 files changed, 488 insertions(+), 251 deletions(-)
diff --git a/hw/xfree86/modes/xf86Crtc.c b/hw/xfree86/modes/xf86Crtc.c
index f977152..f33a228 100644
--- a/hw/xfree86/modes/xf86Crtc.c
+++ b/hw/xfree86/modes/xf86Crtc.c
@@ -104,7 +104,8 @@ xf86CrtcCreate (ScrnInfoPtr scrn,
crtc-rotation = RR_Rotate_0;
crtc-desiredRotation = RR_Rotate_0;
PictureTransformInitIdentity (crtc-crtc_to_framebuffer);
-PictureTransformInitIdentity (crtc-framebuffer_to_crtc);
+pict_f_transform_init_identity (crtc-f_crtc_to_framebuffer);
+pict_f_transform_init_identity (crtc-f_framebuffer_to_crtc);
crtc-filter = NULL;
crtc-params = NULL;
crtc-nparams = 0;
diff --git a/hw/xfree86/modes/xf86Crtc.h b/hw/xfree86/modes/xf86Crtc.h
index d093b1a..026ec78 100644
--- a/hw/xfree86/modes/xf86Crtc.h
+++ b/hw/xfree86/modes/xf86Crtc.h
@@ -305,7 +305,8 @@ struct _xf86Crtc {
* Current transformation matrix
*/
PictTransform crtc_to_framebuffer;
-PictTransform framebuffer_to_crtc;
+struct pict_f_transform f_crtc_to_framebuffer;
+struct pict_f_transform f_framebuffer_to_crtc;
PictFilterPtr filter;
xFixed *params;
intnparams;
diff --git a/hw/xfree86/modes/xf86Cursors.c b/hw/xfree86/modes/xf86Cursors.c
index 7bf9265..4065789 100644
--- a/hw/xfree86/modes/xf86Cursors.c
+++ b/hw/xfree86/modes/xf86Cursors.c
@@ -326,15 +326,13 @@ xf86_crtc_set_cursor_position (xf86CrtcPtr crtc, int x,
int y)
xf86CursorScreenPtr ScreenPriv =
(xf86CursorScreenPtr)dixLookupPrivate(screen-devPrivates,
xf86CursorScreenKey);
- PictVector v;
- x += ScreenPriv-HotX;
- y += ScreenPriv-HotY;
- v.vector[0] = IntToxFixed (x); v.vector[1] = IntToxFixed (y);
v.vector[2] = IntToxFixed(1);
- PictureTransformPoint (crtc-framebuffer_to_crtc, v);
- x = xFixedToInt (v.vector[0]); y = xFixedToInt (v.vector[1]);
- x -= ScreenPriv-HotX;
- y -= ScreenPriv-HotY;
-}
+ struct pict_f_vector v;
+
+ v.v[0] = x + ScreenPriv-HotX; v.v[1] = y + ScreenPriv-HotY; v.v[2] =
1;
+ pict_f_transform_point (crtc-f_framebuffer_to_crtc, v);
+ x = floor (v.v[0] + 0.5) - ScreenPriv-HotX;
+ y = floor (v.v[1] + 0.5) - ScreenPriv-HotY;
+ }
else
{
x -= crtc-x;
diff --git a/hw/xfree86/modes/xf86Rotate.c b/hw/xfree86/modes/xf86Rotate.c
index 7b49afa..efbacec 100644
--- a/hw/xfree86/modes/xf86Rotate.c
+++ b/hw/xfree86/modes/xf86Rotate.c
@@ -122,7 +122,7 @@ xf86RotateCrtcRedisplay (xf86CrtcPtr crtc, RegionPtr region)
dst_box.x2 += crtc-filter_width 1;
dst_box.y1 -= crtc-filter_height 1;
dst_box.y2 += crtc-filter_height 1;
- PictureTransformBounds (dst_box, crtc-framebuffer_to_crtc);
+ pict_f_transform_bounds (crtc-f_framebuffer_to_crtc, dst_box);
CompositePicture (PictOpSrc,
src, NULL, dst,
dst_box.x1, dst_box.y1, 0, 0, dst_box.x1, dst_box.y1,
@@ -165,6 +165,8 @@ xf86CrtcShadowClear (xf86CrtcPtr crtc)
xRectangle rect;
interror;
+if (!dst_pixmap)
+ return;
dst = CreatePicture (None,
dst_pixmap-drawable,
format,
@@ -199,7 +201,6 @@ xf86RotatePrepare (ScreenPtr pScreen)
crtc-rotatedData,
crtc-mode.HDisplay,
crtc-mode.VDisplay);
- xf86CrtcShadowClear (crtc);
if (!xf86_config-rotation_damage_registered)
{
/* Hook damage to screen pixmap */
@@ -355,109 +356,33 @@ xf86CrtcRotate (xf86CrtcPtr crtc, DisplayModePtr mode,
Rotation rotation)
xf86CrtcConfigPtr xf86_config = XF86_CRTC_CONFIG_PTR(pScrn);
/* if this is called during ScreenInit() we don't have pScrn-pScreen yet
*/
ScreenPtr pScreen = screenInfo.screens[pScrn-scrnIndex];
-PictTransform crtc_to_fb, fb_to_crtc;
+PictTransform
[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 index 3d16ede..1f1bea0 100644 --- a/randr/Makefile.am +++ b/randr/Makefile.am @@ -5,7 +5,7 @@ AM_CFLAGS = $(DIX_CFLAGS) XINERAMA_SRCS = rrxinerama.c if XORG -sdk_HEADERS = randrstr.h +sdk_HEADERS = randrstr.h rrtransform.h endif librandr_la_SOURCES = \ -- 1.5.6.5 ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[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 files changed, 35 insertions(+), 23 deletions(-)
diff --git a/hw/xfree86/modes/xf86Rotate.c b/hw/xfree86/modes/xf86Rotate.c
index 75f4a55..865d59c 100644
--- a/hw/xfree86/modes/xf86Rotate.c
+++ b/hw/xfree86/modes/xf86Rotate.c
@@ -135,25 +135,6 @@ xf86RotateCrtcRedisplay (xf86CrtcPtr crtc, RegionPtr
region)
}
static void
-xf86CrtcDamageShadow (xf86CrtcPtr crtc)
-{
-ScrnInfoPtrpScrn = crtc-scrn;
-BoxRec damage_box;
-RegionRec damage_region;
-ScreenPtr pScreen = pScrn-pScreen;
-
-damage_box.x1 = 0;
-damage_box.x2 = crtc-mode.HDisplay;
-damage_box.y1 = 0;
-damage_box.y2 = crtc-mode.VDisplay;
-PictureTransformBounds (damage_box, crtc-crtc_to_framebuffer);
-REGION_INIT (pScreen, damage_region, damage_box, 1);
-DamageRegionAppend((*pScreen-GetScreenPixmap)(pScreen)-drawable,
- damage_region);
-REGION_UNINIT (pScreen, damage_region);
-}
-
-static void
xf86CrtcShadowClear (xf86CrtcPtr crtc)
{
PixmapPtr dst_pixmap = crtc-rotatedPixmap;
@@ -185,6 +166,36 @@ xf86CrtcShadowClear (xf86CrtcPtr crtc)
}
static void
+xf86CrtcDamageShadow (xf86CrtcPtr crtc)
+{
+ScrnInfoPtrpScrn = crtc-scrn;
+BoxRec damage_box;
+RegionRec damage_region;
+ScreenPtr pScreen = pScrn-pScreen;
+
+damage_box.x1 = 0;
+damage_box.x2 = crtc-mode.HDisplay;
+damage_box.y1 = 0;
+damage_box.y2 = crtc-mode.VDisplay;
+if (!PictureTransformBounds (damage_box, crtc-crtc_to_framebuffer))
+{
+ damage_box.x1 = 0;
+ damage_box.y1 = 0;
+ damage_box.x2 = pScreen-width;
+ damage_box.y2 = pScreen-height;
+}
+if (damage_box.x1 0) damage_box.x1 = 0;
+if (damage_box.y1 0) damage_box.y1 = 0;
+if (damage_box.x2 pScreen-width) damage_box.x2 = pScreen-width;
+if (damage_box.y2 pScreen-height) damage_box.y2 = pScreen-height;
+REGION_INIT (pScreen, damage_region, damage_box, 1);
+DamageRegionAppend ((*pScreen-GetScreenPixmap)(pScreen)-drawable,
+ damage_region);
+REGION_UNINIT (pScreen, damage_region);
+xf86CrtcShadowClear (crtc);
+}
+
+static void
xf86RotatePrepare (ScreenPtr pScreen)
{
ScrnInfoPtrpScrn = xf86Screens[pScreen-myNum];
diff --git a/render/matrix.c b/render/matrix.c
index 603281e..560ee94 100644
--- a/render/matrix.c
+++ b/render/matrix.c
@@ -84,7 +84,6 @@ _X_EXPORT Bool
PictureTransformPoint (PictTransformPtr transform,
PictVectorPtrvector)
{
-PictVector result;
inti, j;
xFixed_32_32partial;
xFixed_34_30v[3];
@@ -227,7 +226,7 @@ PictureTransformTranslate (PictTransformPtr forward,
return TRUE;
}
-_X_EXPORT void
+_X_EXPORT Bool
PictureTransformBounds (BoxPtr b, PictTransformPtr matrix)
{
PictVector v[4];
@@ -240,7 +239,8 @@ PictureTransformBounds (BoxPtr b, PictTransformPtr matrix)
v[3].vector[0] = F (b-x1);v[3].vector[1] = F (b-y2); v[3].vector[2]
= F(1);
for (i = 0; i 4; i++)
{
- PictureTransformPoint (matrix, v[i]);
+ if (!PictureTransformPoint (matrix, v[i]))
+ return FALSE;
x1 = xFixedToInt (v[i].vector[0]);
y1 = xFixedToInt (v[i].vector[1]);
x2 = xFixedToInt (xFixedCeil (v[i].vector[0]));
@@ -258,6 +258,7 @@ PictureTransformBounds (BoxPtr b, PictTransformPtr matrix)
if (y2 b-y2) b-y2 = y2;
}
}
+return TRUE;
}
_X_EXPORT Bool
diff --git a/render/picturestr.h b/render/picturestr.h
index 4a7b6e7..ab5dc16 100644
--- a/render/picturestr.h
+++ b/render/picturestr.h
@@ -724,7 +724,7 @@ PictureTransformTranslate (PictTransformPtr forward,
PictTransformPtr reverse,
xFixed tx, xFixed ty);
-void
+Bool
PictureTransformBounds (BoxPtr b, PictTransformPtr matrix);
Bool
--
1.5.6.5
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
[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| 239 ++---
4 files changed, 247 insertions(+), 53 deletions(-)
diff --git a/hw/xfree86/modes/xf86Crtc.h b/hw/xfree86/modes/xf86Crtc.h
index ef8589e..a5bb11b 100644
--- a/hw/xfree86/modes/xf86Crtc.h
+++ b/hw/xfree86/modes/xf86Crtc.h
@@ -306,6 +306,9 @@ struct _xf86Crtc {
*/
PictTransform crtc_to_framebuffer;
PictTransform framebuffer_to_crtc;
+PictFilterPtr filter;
+xFixed *params;
+intnparams;
Bool transform_in_use;
/**
* Bounding box in screen space
diff --git a/hw/xfree86/modes/xf86Rotate.c b/hw/xfree86/modes/xf86Rotate.c
index 7967e5b..f201ae3 100644
--- a/hw/xfree86/modes/xf86Rotate.c
+++ b/hw/xfree86/modes/xf86Rotate.c
@@ -109,6 +109,9 @@ xf86RotateCrtcRedisplay (xf86CrtcPtr crtc, RegionPtr region)
error = SetPictureTransform (src, crtc-crtc_to_framebuffer);
if (error)
return;
+if (crtc-transform_in_use crtc-filter)
+ SetPicturePictFilter (src, crtc-filter,
+ crtc-params, crtc-nparams);
while (n--)
{
@@ -380,13 +383,33 @@ xf86CrtcRotate (xf86CrtcPtr crtc, DisplayModePtr mode,
Rotation rotation)
}
#ifdef RANDR_12_INTERFACE
+if (crtc-randr_crtc)
{
- PictTransform user_forward, user_reverse;
- if (crtc-randr_crtc RRCrtcGetTransform (crtc-randr_crtc,
user_forward, user_reverse))
+ xFixed *new_params = NULL;
+ int new_nparams = 0;
+ PictFilterPtr new_filter = NULL;
+
+ RRTransformPtr transform = RRCrtcGetTransform (crtc-randr_crtc);
+ if (transform)
{
- PictureTransformMultiply (crtc_to_fb, user_forward, crtc_to_fb);
- PictureTransformMultiply (fb_to_crtc, fb_to_crtc, user_reverse);
+ if (transform-nparams) {
+ new_params = xalloc (transform-nparams * sizeof (xFixed));
+ if (new_params) {
+ memcpy (new_params, transform-params,
+ transform-nparams * sizeof (xFixed));
+ new_nparams = transform-nparams;
+ new_filter = transform-filter;
+ }
+ } else
+ new_filter = transform-filter;
+ PictureTransformMultiply (crtc_to_fb, transform-transform,
crtc_to_fb);
+ PictureTransformMultiply (fb_to_crtc, fb_to_crtc,
transform-inverse);
}
+ if (crtc-params)
+ xfree (crtc-params);
+ crtc-params = new_params;
+ crtc-nparams = new_nparams;
+ crtc-filter = new_filter;
}
#endif
/*
diff --git a/randr/randrstr.h b/randr/randrstr.h
index 320e9f7..cdaebe9 100644
--- a/randr/randrstr.h
+++ b/randr/randrstr.h
@@ -78,6 +78,7 @@ typedef struct _rrPropertyValue RRPropertyValueRec,
*RRPropertyValuePtr;
typedef struct _rrProperty RRPropertyRec, *RRPropertyPtr;
typedef struct _rrCrtc RRCrtcRec, *RRCrtcPtr;
typedef struct _rrOutput RROutputRec, *RROutputPtr;
+typedef struct _rrTransformRRTransformRec, *RRTransformPtr;
struct _rrMode {
intrefcnt;
@@ -104,6 +105,14 @@ struct _rrProperty {
RRPropertyValueRec current, pending;
};
+struct _rrTransform {
+PictTransform transform;
+PictTransform inverse;
+PictFilterPtr filter;
+xFixed *params;
+intnparams;
+};
+
struct _rrCrtc {
RRCrtc id;
ScreenPtr pScreen;
@@ -119,10 +128,8 @@ struct _rrCrtc {
CARD16 *gammaBlue;
CARD16 *gammaGreen;
void *devPrivate;
-PictTransform client_pending_transform;
-PictTransform client_pending_inverse;
-PictTransform client_current_transform;
-PictTransform client_current_inverse;
+RRTransformRec client_pending_transform;
+RRTransformRec client_current_transform;
PictTransform transform;
PictTransform inverse;
};
@@ -612,10 +619,8 @@ RRComputeTransform (RRModePtr mode,
/*
* Return crtc transform
*/
-Bool
-RRCrtcGetTransform (RRCrtcPtr crtc,
- PictTransformPtr crtc_to_fb,
- PictTransformPtr fb_to_crtc);
+RRTransformPtr
+RRCrtcGetTransform (RRCrtcPtr crtc);
/*
* Mark the pending transform as current
@@ -643,7 +648,11 @@ RRCrtcDestroy (RRCrtcPtr crtc);
int
RRCrtcTransformSet (RRCrtcPtr crtc,
PictTransformPtrtransform,
- PictTransformPtrinverse);
+ PictTransformPtrinverse,
+ char*filter,
+ int filter_len,
+
[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 _rrTransform {
PictFilterPtr filter;
xFixed *params;
intnparams;
+intwidth;
+intheight;
};
struct _rrCrtc {
diff --git a/randr/rrcrtc.c b/randr/rrcrtc.c
index bae17c5..b715884 100644
--- a/randr/rrcrtc.c
+++ b/randr/rrcrtc.c
@@ -62,7 +62,9 @@ static Bool
RRTransformSetFilter (RRTransformPtr dst,
PictFilterPtr filter,
xFixed*params,
- int nparams)
+ int nparams,
+ int width,
+ int height)
{
xFixed *new_params;
@@ -80,6 +82,8 @@ RRTransformSetFilter (RRTransformPtr dst,
dst-filter = filter;
dst-params = new_params;
dst-nparams = nparams;
+dst-width = width;
+dst-height = height;
return TRUE;
}
@@ -87,7 +91,7 @@ static Bool
RRTransformCopy (RRTransformPtr dst, RRTransformPtr src)
{
if (!RRTransformSetFilter (dst, src-filter,
- src-params, src-nparams))
+ src-params, src-nparams, src-width,
src-height))
return FALSE;
dst-transform = src-transform;
dst-inverse = src-inverse;
@@ -602,6 +606,7 @@ RRCrtcTransformSet (RRCrtcPtr crtc,
int nparams)
{
PictFilterPtr filter = NULL;
+intwidth = 0, height = 0;
if (!PictureTransformIsInverse (transform, inverse))
return BadMatch;
@@ -615,9 +620,13 @@ RRCrtcTransformSet (RRCrtcPtr crtc,
if (filter-ValidateParams)
{
if (!filter-ValidateParams (crtc-pScreen, filter-id,
-params, nparams))
+params, nparams, width, height))
return BadMatch;
}
+ else {
+ width = filter-width;
+ height = filter-height;
+ }
}
else
{
@@ -625,7 +634,7 @@ RRCrtcTransformSet (RRCrtcPtr crtc,
return BadMatch;
}
if (!RRTransformSetFilter (crtc-client_pending_transform,
- filter, params, nparams))
+ filter, params, nparams, width, height))
return BadAlloc;
crtc-client_pending_transform.transform = *transform;
@@ -1037,12 +1046,11 @@ ProcRRSetCrtcConfig (ClientPtr client)
int source_height;
PictTransform transform, inverse;
- if (!RRComputeTransform (mode, stuff-rotation,
-stuff-x, stuff-y,
-crtc-client_pending_transform.transform,
-crtc-client_pending_transform.inverse,
-transform, inverse))
- return BadMatch;
+ RRComputeTransform (mode, stuff-rotation,
+ stuff-x, stuff-y,
+ crtc-client_pending_transform.transform,
+ crtc-client_pending_transform.inverse,
+ transform, inverse);
RRModeGetScanoutSize (mode, transform, source_width,
source_height);
if (stuff-x + source_width pScreen-width)
--
1.5.6.5
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
[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 e499fc4..b5bcf02 100644
--- a/render/filter.c
+++ b/render/filter.c
@@ -126,7 +126,9 @@ PictureFreeFilterIds (void)
_X_EXPORT int
PictureAddFilter (ScreenPtrpScreen,
char *filter,
- PictFilterValidateParamsProcPtr ValidateParams)
+ PictFilterValidateParamsProcPtr ValidateParams,
+ int width,
+ int height)
{
PictureScreenPtrps = GetPictureScreen(pScreen);
intid = PictureGetFilterId (filter, -1, TRUE);
@@ -152,6 +154,8 @@ PictureAddFilter (ScreenPtr pScreen,
ps-filters[i].name = PictureGetFilterName (id);
ps-filters[i].id = id;
ps-filters[i].ValidateParams = ValidateParams;
+ps-filters[i].width = width;
+ps-filters[i].height = height;
return id;
}
@@ -216,18 +220,26 @@ static Bool
convolutionFilterValidateParams (ScreenPtr pScreen,
int filter,
xFixed *params,
- int nparams)
+ int nparams,
+int *width,
+int *height)
{
+intw, h;
if (nparams 3)
return FALSE;
if (xFixedFrac (params[0]) || xFixedFrac (params[1]))
return FALSE;
+w = xFixedToInt (params[0]);
+h = xFixedToInt (params[1]);
+
nparams -= 2;
-if ((xFixedToInt (params[0]) * xFixedToInt (params[1])) nparams)
+if (w * h nparams)
return FALSE;
+*width = w;
+*height = h;
return TRUE;
}
@@ -238,9 +250,9 @@ PictureSetDefaultFilters (ScreenPtr pScreen)
if (!filterNames)
if (!PictureSetDefaultIds ())
return FALSE;
-if (PictureAddFilter (pScreen, FilterNearest, 0) 0)
+if (PictureAddFilter (pScreen, FilterNearest, 0, 1, 1) 0)
return FALSE;
-if (PictureAddFilter (pScreen, FilterBilinear, 0) 0)
+if (PictureAddFilter (pScreen, FilterBilinear, 0, 4, 4) 0)
return FALSE;
if (!PictureSetFilterAlias (pScreen, FilterNearest, FilterFast))
@@ -250,7 +262,7 @@ PictureSetDefaultFilters (ScreenPtr pScreen)
if (!PictureSetFilterAlias (pScreen, FilterBilinear, FilterBest))
return FALSE;
-if (PictureAddFilter (pScreen, FilterConvolution,
convolutionFilterValidateParams) 0)
+if (PictureAddFilter (pScreen, FilterConvolution,
convolutionFilterValidateParams, 0, 0) 0)
return FALSE;
return TRUE;
@@ -314,7 +326,8 @@ SetPicturePictFilter (PicturePtr pPicture, PictFilterPtr
pFilter,
if (pFilter-ValidateParams)
{
- if (!(*pFilter-ValidateParams) (pScreen, pFilter-id, params, nparams))
+ int width, height;
+ if (!(*pFilter-ValidateParams) (pScreen, pFilter-id, params, nparams,
width, height))
return BadMatch;
}
else if (nparams)
diff --git a/render/picturestr.h b/render/picturestr.h
index 8a926ce..60be68a 100644
--- a/render/picturestr.h
+++ b/render/picturestr.h
@@ -185,11 +185,13 @@ typedef struct _Picture {
} PictureRec;
typedef Bool (*PictFilterValidateParamsProcPtr) (ScreenPtr pScreen, int id,
-xFixed *params, int nparams);
+xFixed *params, int nparams,
+int *width, int *height);
typedef struct {
char *name;
intid;
PictFilterValidateParamsProcPtr ValidateParams;
+intwidth, height;
} PictFilterRec, *PictFilterPtr;
#define PictFilterNearest 0
@@ -458,7 +460,9 @@ PictureGetFilterName (int id);
int
PictureAddFilter (ScreenPtrpScreen,
char *filter,
- PictFilterValidateParamsProcPtr ValidateParams);
+ PictFilterValidateParamsProcPtr ValidateParams,
+ int width,
+ int height);
Bool
PictureSetFilterAlias (ScreenPtr pScreen, char *filter, char *alias);
--
1.5.6.5
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
[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 @@ xf86CrtcCreate (ScrnInfoPtrscrn, #endif crtc-rotation = RR_Rotate_0; crtc-desiredRotation = RR_Rotate_0; +PictureTransformInitIdentity (crtc-crtc_to_framebuffer); +PictureTransformInitIdentity (crtc-framebuffer_to_crtc); +crtc-filter = NULL; +crtc-params = NULL; +crtc-nparams = 0; +crtc-filter_width = 0; +crtc-filter_height = 0; +crtc-transform_in_use = FALSE; +memset (crtc-bounds, '\0', sizeof (crtc-bounds)); + if (xf86_config-crtc) crtcs = xrealloc (xf86_config-crtc, (xf86_config-num_crtc + 1) * sizeof (xf86CrtcPtr)); @@ -134,6 +144,8 @@ xf86CrtcDestroy (xf86CrtcPtr crtc) xf86_config-num_crtc--; break; } +if (crtc-params) + xfree (crtc-params); xfree (crtc); } -- 1.5.6.5 ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[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; if (PictureAddFilter (pScreen, FilterNearest, 0, 1, 1) 0) return FALSE; -if (PictureAddFilter (pScreen, FilterBilinear, 0, 4, 4) 0) +if (PictureAddFilter (pScreen, FilterBilinear, 0, 2, 2) 0) return FALSE; if (!PictureSetFilterAlias (pScreen, FilterNearest, FilterFast)) -- 1.5.6.5 ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[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(-)
diff --git a/render/matrix.c b/render/matrix.c
index 6e50205..0d5d962 100644
--- a/render/matrix.c
+++ b/render/matrix.c
@@ -72,9 +72,9 @@ PictureTransformPoint3d (PictTransformPtr transform,
return FALSE;
result.vector[j] = (xFixed) v;
}
+*vector = result;
if (!result.vector[2])
return FALSE;
-*vector = result;
return TRUE;
}
@@ -286,7 +286,8 @@ from_doubles (PictTransformPtr t, double m[3][3])
double d = m[j][i];
if (d -32767.0 || d 32767.0)
return FALSE;
- t-matrix[j][i] = pixman_double_to_fixed (d);
+ d = d * 65536.0 + 0.5;
+ t-matrix[j][i] = (xFixed) floor (d);
}
return TRUE;
}
@@ -294,7 +295,7 @@ from_doubles (PictTransformPtr t, double m[3][3])
static Bool
invert (double r[3][3], double m[3][3])
{
-double det, norm;
+double det;
inti, j;
static int a[3] = { 2, 2, 1 };
static int b[3] = { 1, 0, 0 };
--
1.5.6.5
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
[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 a/render/matrix.c b/render/matrix.c
index a976304..6e50205 100644
--- a/render/matrix.c
+++ b/render/matrix.c
@@ -262,6 +262,86 @@ PictureTransformBounds (BoxPtr b, PictTransformPtr matrix)
}
}
+static const int a[3] = { 3, 3, 2 };
+static const int b[3] = { 2, 1, 1 };
+
+static void
+to_doubles (double m[3][3], const PictTransformPtr t)
+{
+inti, j;
+
+for (j = 0; j 3; j++)
+ for (i = 0; i 3; i++)
+ m[j][i] = pixman_fixed_to_double (t-matrix[j][i]);
+}
+
+static Bool
+from_doubles (PictTransformPtr t, double m[3][3])
+{
+inti, j;
+
+for (j = 0; j 3; j++)
+ for (i = 0; i 3; i++)
+ {
+ double d = m[j][i];
+ if (d -32767.0 || d 32767.0)
+ return FALSE;
+ t-matrix[j][i] = pixman_double_to_fixed (d);
+ }
+return TRUE;
+}
+
+static Bool
+invert (double r[3][3], double m[3][3])
+{
+double det, norm;
+inti, j;
+static int a[3] = { 2, 2, 1 };
+static int b[3] = { 1, 0, 0 };
+
+det = 0;
+for (i = 0; i 3; i++) {
+ double p;
+ int ai = a[i];
+ int bi = b[i];
+ p = m[i][0] * (m[ai][2] * m[bi][1] - m[ai][1] * m[bi][2]);
+ if (i == 1)
+ p = -p;
+ det += p;
+}
+if (det == 0)
+ return FALSE;
+det = 1/det;
+for (j = 0; j 3; j++) {
+ for (i = 0; i 3; i++) {
+ double p;
+ int ai = a[i];
+ int aj = a[j];
+ int bi = b[i];
+ int bj = b[j];
+
+ p = m[ai][aj] * m[bi][bj] - m[ai][bj] * m[bi][aj];
+ if (((i + j) 1) != 0)
+ p = -p;
+ r[j][i] = det * p;
+ }
+}
+return TRUE;
+}
+
+_X_EXPORT Bool
+PictureTransformInvert (PictTransformPtr dst, const PictTransformPtr src)
+{
+double m[3][3], r[3][3];
+
+to_doubles (m, src);
+if (!invert (r, m))
+ return FALSE;
+if (!from_doubles (dst, r))
+ return FALSE;
+return TRUE;
+}
+
static Bool
within_epsilon (xFixed a, xFixed b, xFixed epsilon)
{
diff --git a/render/picturestr.h b/render/picturestr.h
index 60be68a..658e221 100644
--- a/render/picturestr.h
+++ b/render/picturestr.h
@@ -720,6 +720,9 @@ void
PictureTransformBounds (BoxPtr b, PictTransformPtr matrix);
Bool
+PictureTransformInvert (PictTransformPtr dst, const PictTransformPtr src);
+
+Bool
PictureTransformIsIdentity(PictTransform *t);
Bool
--
1.5.6.5
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
[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 +
hw/xfree86/modes/xf86RandR12.h |1 +
randr/randrstr.h |7 +++
randr/rrcrtc.c | 15 +--
5 files changed, 52 insertions(+), 2 deletions(-)
diff --git a/hw/xfree86/modes/xf86Crtc.c b/hw/xfree86/modes/xf86Crtc.c
index 35c1190..f977152 100644
--- a/hw/xfree86/modes/xf86Crtc.c
+++ b/hw/xfree86/modes/xf86Crtc.c
@@ -735,11 +735,17 @@ xf86CrtcScreenInit (ScreenPtr screen)
break;
}
if (c == config-num_crtc)
+{
xf86RandR12SetRotations (screen, RR_Rotate_0 | RR_Rotate_90 |
RR_Rotate_180 | RR_Rotate_270 |
RR_Reflect_X | RR_Reflect_Y);
+ xf86RandR12SetTransform (screen, TRUE);
+}
else
+{
xf86RandR12SetRotations (screen, RR_Rotate_0);
+ xf86RandR12SetTransform (screen, FALSE);
+}
/* Wrap CreateScreenResources so we can initialize the RandR code */
config-CreateScreenResources = screen-CreateScreenResources;
diff --git a/hw/xfree86/modes/xf86RandR12.c b/hw/xfree86/modes/xf86RandR12.c
index 6e14bd7..f247a88 100644
--- a/hw/xfree86/modes/xf86RandR12.c
+++ b/hw/xfree86/modes/xf86RandR12.c
@@ -569,6 +569,31 @@ xf86RandR12SetRotations (ScreenPtr pScreen, Rotation
rotations)
}
_X_EXPORT void
+xf86RandR12SetTransform (ScreenPtr pScreen, Bool transforms)
+{
+XF86RandRInfoPtr randrp;
+#if RANDR_13_INTERFACE
+ScrnInfoPtrpScrn = xf86Screens[pScreen-myNum];
+intc;
+xf86CrtcConfigPtr config = XF86_CRTC_CONFIG_PTR(pScrn);
+#endif
+
+#if XORG_VERSION_CURRENT XORG_VERSION_NUMERIC(7,0,0,0,0)
+if (xf86RandR12Key == NULL)
+ return;
+#endif
+
+randrp = XF86RANDRINFO(pScreen);
+#if RANDR_13_INTERFACE
+for (c = 0; c config-num_crtc; c++) {
+ xf86CrtcPtrcrtc = config-crtc[c];
+
+ RRCrtcSetTransform (crtc-randr_crtc, transforms);
+}
+#endif
+}
+
+_X_EXPORT void
xf86RandR12GetOriginalVirtualSize(ScrnInfoPtr pScrn, int *x, int *y)
{
ScreenPtr pScreen = screenInfo.screens[pScrn-scrnIndex];
diff --git a/hw/xfree86/modes/xf86RandR12.h b/hw/xfree86/modes/xf86RandR12.h
index 4fd855c..c361b47 100644
--- a/hw/xfree86/modes/xf86RandR12.h
+++ b/hw/xfree86/modes/xf86RandR12.h
@@ -31,6 +31,7 @@
Bool xf86RandR12CreateScreenResources (ScreenPtr pScreen);
Bool xf86RandR12Init(ScreenPtr pScreen);
void xf86RandR12SetRotations (ScreenPtr pScreen, Rotation rotation);
+void xf86RandR12SetTransform (ScreenPtr pScreen, Bool transforms);
Bool xf86RandR12SetConfig(ScreenPtr pScreen, Rotation rotation, int rate,
RRScreenSizePtr pSize);
Rotation xf86RandR12GetRotation(ScreenPtr pScreen);
diff --git a/randr/randrstr.h b/randr/randrstr.h
index 17d0a8b..792c3d6 100644
--- a/randr/randrstr.h
+++ b/randr/randrstr.h
@@ -130,6 +130,7 @@ struct _rrCrtc {
CARD16 *gammaBlue;
CARD16 *gammaGreen;
void *devPrivate;
+Bool transforms;
RRTransformRec client_pending_transform;
RRTransformRec client_current_transform;
PictTransform transform;
@@ -539,6 +540,12 @@ void
RRCrtcSetRotations (RRCrtcPtr crtc, Rotation rotations);
/*
+ * Set whether transforms are allowed on a CRTC
+ */
+void
+RRCrtcSetTransform (RRCrtcPtr crtc, Bool transforms);
+
+/*
* Notify the extension that the Crtc has been reconfigured,
* the driver calls this whenever it has updated the mode
*/
diff --git a/randr/rrcrtc.c b/randr/rrcrtc.c
index b8b9ec0..6559d51 100644
--- a/randr/rrcrtc.c
+++ b/randr/rrcrtc.c
@@ -164,6 +164,15 @@ RRCrtcSetRotations (RRCrtcPtr crtc, Rotation rotations)
}
/*
+ * Set whether transforms are allowed on a CRTC
+ */
+void
+RRCrtcSetTransform (RRCrtcPtr crtc, Bool transforms)
+{
+crtc-transforms = transforms;
+}
+
+/*
* Notify the extension that the Crtc has been reconfigured,
* the driver calls this whenever it has updated the mode
*/
@@ -608,6 +617,9 @@ RRCrtcTransformSet (RRCrtcPtr crtc,
PictFilterPtr filter = NULL;
intwidth = 0, height = 0;
+if (!crtc-transforms)
+ return BadValue;
+
if (filter_len)
{
filter = PictureFindFilter (crtc-pScreen,
@@ -1326,8 +1338,7 @@ ProcRRGetCrtcTransform (ClientPtr client)
reply-sequenceNumber = client-sequence;
reply-length = (CrtcTransformExtra + nextra) 2;
-/* XXX deal with DDXen that can't do transforms */
-reply-hasTransforms = xTrue;
+reply-hasTransforms = crtc-transforms;
transform_encode (client, reply-pendingTransform, pending-transform);
transform_encode (client, reply-pendingInverse, pending-inverse);
--
1.5.6.5
[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 @@ RRCrtcNotify (RRCrtcPtrcrtc,
RRTransformCopy (crtc-client_current_transform, transform);
RRCrtcChanged (crtc, TRUE);
}
+if (crtc-changed)
+{
+ RRTransformCompute (x, y,
+ mode-mode.width, mode-mode.height,
+ rotation,
+ crtc-client_current_transform,
+ crtc-transform, crtc-f_transform,
+ crtc-f_inverse);
+}
return TRUE;
}
--
1.5.6.5
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
[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 +
hw/xfree86/modes/xf86RandR12.h |2 +-
hw/xfree86/modes/xf86Rename.h |1 +
hw/xfree86/modes/xf86Rotate.c | 50 +++
randr/randrstr.h |4 +-
randr/rrcrtc.c | 56 ---
8 files changed, 150 insertions(+), 66 deletions(-)
diff --git a/hw/xfree86/modes/xf86Crtc.c b/hw/xfree86/modes/xf86Crtc.c
index f33a228..e3a852e 100644
--- a/hw/xfree86/modes/xf86Crtc.c
+++ b/hw/xfree86/modes/xf86Crtc.c
@@ -237,8 +237,8 @@ xf86CrtcSetScreenSubpixelOrder (ScreenPtr pScreen)
* Sets the given video mode on the given crtc
*/
_X_EXPORT Bool
-xf86CrtcSetMode (xf86CrtcPtr crtc, DisplayModePtr mode, Rotation rotation,
-int x, int y)
+xf86CrtcSetModeTransform (xf86CrtcPtr crtc, DisplayModePtr mode, Rotation
rotation,
+ RRTransformPtr transform, int x, int y)
{
ScrnInfoPtrscrn = crtc-scrn;
xf86CrtcConfigPtr xf86_config = XF86_CRTC_CONFIG_PTR(scrn);
@@ -249,6 +249,8 @@ xf86CrtcSetMode (xf86CrtcPtr crtc, DisplayModePtr mode,
Rotation rotation,
DisplayModeRec saved_mode;
intsaved_x, saved_y;
Rotation saved_rotation;
+RRTransformRec saved_transform;
+Bool saved_transform_present;
if (crtc-funcs-set_mode_major)
return crtc-funcs-set_mode_major(crtc, mode, rotation, x, y);
@@ -269,6 +271,9 @@ xf86CrtcSetMode (xf86CrtcPtr crtc, DisplayModePtr mode,
Rotation rotation,
saved_x = crtc-x;
saved_y = crtc-y;
saved_rotation = crtc-rotation;
+saved_transform = crtc-transform;
+saved_transform_present = crtc-transformPresent;
+
/* Update crtc values up front so the driver can rely on them for mode
* setting.
*/
@@ -276,6 +281,11 @@ xf86CrtcSetMode (xf86CrtcPtr crtc, DisplayModePtr mode,
Rotation rotation,
crtc-x = x;
crtc-y = y;
crtc-rotation = rotation;
+if (transform) {
+ crtc-transform = *transform;
+ crtc-transformPresent = TRUE;
+} else
+ crtc-transformPresent = FALSE;
/* Shift offsets that move us out of virtual size */
if (x + mode-HDisplay xf86_config-maxWidth ||
@@ -322,9 +332,8 @@ xf86CrtcSetMode (xf86CrtcPtr crtc, DisplayModePtr mode,
Rotation rotation,
goto done;
}
-if (!xf86CrtcRotate (crtc, mode, rotation)) {
+if (!xf86CrtcRotate (crtc))
goto done;
-}
/* Prepare the outputs and CRTCs before setting the mode. */
for (i = 0; i xf86_config-num_output; i++) {
@@ -356,17 +365,11 @@ xf86CrtcSetMode (xf86CrtcPtr crtc, DisplayModePtr mode,
Rotation rotation,
{
xf86OutputPtr output = xf86_config-output[i];
if (output-crtc == crtc)
- {
output-funcs-commit(output);
-#ifdef RANDR_12_INTERFACE
- if (output-randr_output)
- RRPostPendingProperties (output-randr_output);
-#endif
- }
}
#ifdef RANDR_12_INTERFACE
if (crtc-randr_crtc)
- RRCrtcPostPendingTransform (crtc-randr_crtc);
+ RRCrtcSetTransform (crtc-randr_crtc, transform);
#endif
/* XXX free adjustedmode */
@@ -380,6 +383,8 @@ done:
crtc-y = saved_y;
crtc-rotation = saved_rotation;
crtc-mode = saved_mode;
+ crtc-transform = saved_transform;
+ crtc-transformPresent = saved_transform_present;
}
if (didLock)
@@ -388,6 +393,17 @@ done:
return ret;
}
+/**
+ * Sets the given video mode on the given crtc, but without providing
+ * a transform
+ */
+_X_EXPORT Bool
+xf86CrtcSetMode (xf86CrtcPtr crtc, DisplayModePtr mode, Rotation rotation,
+int x, int y)
+{
+return xf86CrtcSetModeTransform (crtc, mode, rotation, NULL, x, y);
+}
+
/*
* Output functions
*/
@@ -740,12 +756,12 @@ xf86CrtcScreenInit (ScreenPtr screen)
xf86RandR12SetRotations (screen, RR_Rotate_0 | RR_Rotate_90 |
RR_Rotate_180 | RR_Rotate_270 |
RR_Reflect_X | RR_Reflect_Y);
- xf86RandR12SetTransform (screen, TRUE);
+ xf86RandR12SetTransformSupport (screen, TRUE);
}
else
{
xf86RandR12SetRotations (screen, RR_Rotate_0);
- xf86RandR12SetTransform (screen, FALSE);
+ xf86RandR12SetTransformSupport (screen, FALSE);
}
/* Wrap CreateScreenResources so we can initialize the RandR code */
@@ -2200,6 +2216,7 @@ xf86InitialConfiguration (ScrnInfoPtr scrn, Bool canGrow)
crtc-desiredRotation = output-initial_rotation;
crtc-desiredX = output-initial_x;
crtc-desiredY = output-initial_y;
+
[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 @@ xf86CrtcSetModeTransform (xf86CrtcPtr crtc, DisplayModePtr
mode, Rotation rotati
saved_x = crtc-x;
saved_y = crtc-y;
saved_rotation = crtc-rotation;
-saved_transform = crtc-transform;
+if (crtc-transformPresent) {
+ RRTransformInit (saved_transform);
+ RRTransformCopy (saved_transform, crtc-transform);
+}
saved_transform_present = crtc-transformPresent;
/* Update crtc values up front so the driver can rely on them for mode
@@ -283,7 +286,6 @@ xf86CrtcSetModeTransform (xf86CrtcPtr crtc, DisplayModePtr
mode, Rotation rotati
crtc-rotation = rotation;
if (transform) {
RRTransformCopy (crtc-transform, transform);
- crtc-transform = *transform;
crtc-transformPresent = TRUE;
} else
crtc-transformPresent = FALSE;
@@ -380,7 +382,8 @@ done:
crtc-y = saved_y;
crtc-rotation = saved_rotation;
crtc-mode = saved_mode;
- crtc-transform = saved_transform;
+ if (saved_transform_present)
+ RRTransformCopy (crtc-transform, saved_transform);
crtc-transformPresent = saved_transform_present;
}
--
1.5.6.5
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
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 for large scales (like 100x). A patch would be welcome; the internals are mostly ready now. -- [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X server 1.6 release schedule
On Mon, 2008-11-17 at 13:08 +0100, Matthias Hopf wrote: Keith, AFAICS the standard properties do not inflict any changes on server code except for the naming of the EDID data property, so I assume that's fine here. Yup. I'm unsure whether it would be wise to include panning support in 1.3, even given that I manage to put it together until 11/24. I guess it should settle in master first. I'd like to get panning into 1.6; it's not a huge driver change as we already support all of the needed functionality. In that case, do we have any protocol changes in 1.3? Do we need a version bump then? The projective transforms require a protocol bump, hence wanting to get all of the RandR 1.3 protocol changes included. -- [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [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 PROTECTED] signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [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 modification. Someday we'll clean this stuff up... -- [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X server 1.6 release schedule
On Tue, 2008-11-18 at 18:23 -0500, Adam Jackson wrote: Overscan correction? I don't think this counts as a subset of projective transforms, but I could be wrong. No, not a part of projective transforms as it doesn't change the pixel-pixel mapping. It sounds useful; get some code together along with a spec update and we can ship it too. -- [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X server 1.6 release schedule
On Wed, 2008-11-19 at 10:12 -0500, Adam Jackson wrote: I think it's most natural to do this as additional border fields in a MODEINFO. Imagine a new definition: I'd say adding a new border size and color request would be easier; you'd set the pending border size/color and then set the mode, just like properties. One question is whether we'd bother doing a driver-specific API or whether we'd just allocate the larger frame buffer, paint the border, and then just use a subset of that for the screen. We already separate out the projected size of the crtc (that portion of the screen represented in the crtc) from the mode size; that's necessary for rotation and other transforms. -- [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X server 1.6 release schedule
On Wed, 2008-11-19 at 13:55 +0100, Éric Piel wrote: Keith Packard schreef: On Tue, 2008-11-18 at 14:42 -0500, Adam Jackson wrote: Hello, Can we define what RANDR 1.3 means? I think we're largely in agreement but I'd like it written down. I think RandR 1.3 includes: 1. Projective transforms 2. Standard properties 3. Per-CRTC DPMS controls 4. Panning Will it also include the additional functions for the applications to know about the screens topology without re-scanning all the outputs. This was discussed with GTK leading to a flickering display each time a new application was started. Adam proposed this patch then: http://people.freedesktop.org/~ajax/patches/randrproto-1.3.patch Yeah, I didn't get that into the above list. I'm not sure I like the 'same information, but no query' plan; I don't think we need to return the possible mode information, just the current settings. -- [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[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, 743 insertions(+), 34 deletions(-)
create mode 100644 pixman/pixman-matrix.c
diff --git a/configure.ac b/configure.ac
index 7937f95..063f6eb 100644
--- a/configure.ac
+++ b/configure.ac
@@ -54,7 +54,7 @@ AC_PREREQ([2.57])
m4_define([pixman_major], 0)
m4_define([pixman_minor], 13)
-m4_define([pixman_micro], 1)
+m4_define([pixman_micro], 2)
m4_define([pixman_version],[pixman_major.pixman_minor.pixman_micro])
diff --git a/pixman/Makefile.am b/pixman/Makefile.am
index 6d5a643..c4612ea 100644
--- a/pixman/Makefile.am
+++ b/pixman/Makefile.am
@@ -26,7 +26,8 @@ libpixman_1_la_SOURCES = \
pixman-edge-imp.h \
pixman-trap.c \
pixman-compute-region.c \
- pixman-timer.c
+ pixman-timer.c \
+ pixman-matrix.c
libpixmanincludedir = $(includedir)/pixman-1/
libpixmaninclude_HEADERS = pixman.h pixman-version.h
diff --git a/pixman/pixman-matrix.c b/pixman/pixman-matrix.c
new file mode 100644
index 000..ce5d77f
--- /dev/null
+++ b/pixman/pixman-matrix.c
@@ -0,0 +1,594 @@
+/*
+ * Copyright © 2008 Keith Packard
+ *
+ * Permission to use, copy, modify, distribute, and sell this software and its
+ * documentation for any purpose is hereby granted without fee, provided that
+ * the above copyright notice appear in all copies and that both that copyright
+ * notice and this permission notice appear in supporting documentation, and
+ * that the name of the copyright holders not be used in advertising or
+ * publicity pertaining to distribution of the software without specific,
+ * written prior permission. The copyright holders make no representations
+ * about the suitability of this software for any purpose. It is provided as
+ * is without express or implied warranty.
+ *
+ * THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS SOFTWARE,
+ * INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO
+ * EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY SPECIAL, INDIRECT OR
+ * CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE,
+ * DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER
+ * TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE
+ * OF THIS SOFTWARE.
+ */
+
+/*
+ * Floating point matrix interfaces
+ */
+
+#include config.h
+#include math.h
+#include string.h
+#include pixman-private.h
+
+#define F(x) pixman_int_to_fixed(x)
+
+PIXMAN_EXPORT void
+pixman_transform_init_identity(struct pixman_transform *matrix)
+{
+ int i;
+
+ memset(matrix, '\0', sizeof (struct pixman_transform));
+ for (i = 0; i 3; i++)
+ matrix-matrix[i][i] = F(1);
+}
+
+typedef pixman_fixed_32_32_t pixman_fixed_34_30_t;
+
+PIXMAN_EXPORT pixman_bool_t
+pixman_transform_point_3d(struct pixman_transform *transform,
+ struct pixman_vector *vector)
+{
+ struct pixman_vector result;
+ pixman_fixed_32_32_t partial;
+ pixman_fixed_48_16_t v;
+ int i, j;
+
+ for (j = 0; j 3; j++)
+ {
+ v = 0;
+ for (i = 0; i 3; i++)
+ {
+ partial = ((pixman_fixed_48_16_t)
transform-matrix[j][i] *
+ (pixman_fixed_48_16_t) vector-vector[i]);
+ v += partial 16;
+ }
+ if (v pixman_max_fixed_48_16 || v pixman_min_fixed_48_16)
+ return FALSE;
+ result.vector[j] = (pixman_fixed_t) v;
+ }
+ *vector = result;
+ if (!result.vector[2])
+ return FALSE;
+ return TRUE;
+}
+
+PIXMAN_EXPORT pixman_bool_t
+pixman_transform_point(struct pixman_transform *transform,
+ struct pixman_vector *vector)
+{
+ pixman_fixed_32_32_t partial;
+ pixman_fixed_34_30_t v[3];
+ pixman_fixed_48_16_t quo;
+ int i, j;
+
+ for (j = 0; j 3; j++)
+ {
+ v[j] = 0;
+ for (i = 0; i 3; i++)
+ {
+ partial = ((pixman_fixed_32_32_t)
transform-matrix[j][i] *
+ (pixman_fixed_32_32_t) vector-vector[i]);
+ v[j] += partial 2;
+ }
+ }
+ if (!v[2])
+ return FALSE;
+ for (j = 0; j 2; j++)
+ {
+ quo = v[j] / (v[2] 16);
+ if (quo pixman_max_fixed_48_16 || quo
pixman_min_fixed_48_16)
+ return FALSE;
+ vector-vector[j] = (pixman_fixed_t) quo;
+ }
+ vector-vector[2] = pixman_fixed_1
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 that depends on pixman beta bits, but I don't want to ship an X server that requires unreviewed code. 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. -- [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X server 1.6_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 review all the numericals, but nothing jumped out at me either. I just copied the code from the X server where it hasn't demonstrated any problems. I think most of the paths are actually tested in the projective transform RandR work too. - I'd like to have the interface const correct, for example in pixman_transform_multily (struct pixman_transform_t *dst, struct pixman_transform_t *l, struct pixman_transform_t *r); Yeah, I briefly considered doing that; I'll go fix it. - For the rotation interfaces, maybe expand the names s and c to sin and cos? I first thought c meant center and was then mystified what s could mean. Ok. - The interfaces that take forward/reverse matrices should probably accept NULL's. Ok. - Pixman's version numbering scheme is similar to cairo's: The git master version has an odd micro number, released versions have even micro numbers. What version would you like? - The name pixman_f_transform bothers me, but I don't have a better suggestion since pixman_transformf would be worse. I'll leave this alone then. - Is there any particular reason for the fixed point epsilon of 2 (as opposed to 1)? Just giving more space to allow for rounding errors. - There is a comment about floating point interfaces, but the file contains both fixed and floating point interfaces. I'll fix the comment. Thanks for the review! -- [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: 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, /* 26 */ I guess ProcRRGetScreenResourcesCurrent is missing... oops! Fixing. -- [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [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 Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
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 made some arithmetic blunder). -- [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [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 make back-porting XI2 to 1.6 servers a bit easier. Leave it in? Take it out? -- [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [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 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, no, I don't care what the defined behaviour is (it could be as simple as 'panning is disabled on any screen size change'). + ┌─── 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. + Same here -- don't leave this undefined. 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. 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. + 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. I'd say all of this timestamp stuff can be eliminated. + '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 disable panning in one dimension while leaving it enabled in the other. Also, if width == crtc_width and height == crtc_height, then panning is disabled entirely. You could make width == 0 mean to set width to the crtc_width (like ClearArea does). + '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? +
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 check for transformation changes? And output
property changes?
+/**
+ * Pans the screen, does not change the mode
+ */
Should we call the low-level operation 'set_origin' instead of 'pan'?
+int pointerX;
+int pointerY;
I'd prefer to not shadow the pointer position inside RandR; is there
some way we can use the DIX pointer position here?
We should also start to consider how MPX plays with panning.
+static Bool
+xf86RandR13SetPanning (ScreenPtr pScreen,
+RRCrtcPtr randr_crtc,
+BoxPtr totalArea,
+BoxPtr trackingArea,
+INT16 *border)
+{
+XF86RandRInfoPtr randrp = XF86RANDRINFO(pScreen);
+xf86CrtcPtr crtc = randr_crtc-devPrivate;
+int ret;
+
+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
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.
--
[EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [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 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. 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. 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. 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. The same is true of modes. 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 match (and the hardware supports it). Adding an additional sharing constraint based on panning should be easy. 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. Thanks. I wanted to do this quite a while ago, but never got around to it. 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. A separate call is better. -- [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [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 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) 1.2.99.1, I think. Then we move to 1.3.0 when we ship this stuff. -- [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [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.
typedef struct {
+ BYTE type;
+ CARD8 pad;
+ CARD16 sequenceNumber B16;
+ CARD32 length B32;
+ RROutput output B32;
+} xRRGetOutputPrimaryReply;
+#define sz_xRRGetOutputPrimaryReply 12
Replies are always at least 32 bytes. (the length field indicates the
number of 4-byte units beyond the initial 32-byte header). You'll have
to pad this out to make it work.
+ The
+ default primary output is None, and None is a legal value to pass
+ to RRSetOutputPrimary.
I suspect drivers will want to set the default primary output to
something other than None -- on a laptop, one can imagine always making
the LVDS 'primary'. Something that lets the server set it to whatever it
likes at startup and yet leaves the semantics of None well defined
should work.
Otherwise, this looks good. Let me know when it's working :-)
--
[EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [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 settings fail and if the application has no recovery mechanism (which is likely), the user is left confused. It's been a serious problem in the past, and the timestamps don't eliminate inter-application races, they just narrow the window. 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. 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 region. So, some alternative specification mechanism is required, either the border values that you're using, or an offset rectangle which is specified relative to the current CRTC origin. 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. 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). -- [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
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 frame buffer size along with the panning area. -- [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: 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 for 1.6 and start preparing for the release. -- [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: 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 hardware has built-in DP support, but the driver doesn't work with it yet. I'm working on it, but it's harder than HDMI to get running. I spent a day and got the chipset talking to the monitor, but no output yet. And no EDID yet either; the DDC stuff uses the DP AUX CH in a mystic way. -- keith.pack...@intel.com signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
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 logical move. I believe (without proof) that the only windows which should receive events for any pointer motion are precisely the set of windows which would have received events under the core protocol with only a single pointer. That would mean that all we have to do is compute *which* event each one of those windows receives. Using (as Owen did) P(W) to represent the pointer window as seen by W, we walk the set of windows that are to receive events, compute P(W) (the old pointer window) and P'(W) (the new pointer window) and use those two windows to construct the correct event to deliver to W. Here's some deconstruction of your specific instructions: (X..Y) windows from X to Y not including X or Y [X..Y) windows from X to Y including X but not Y (X..Y] windows from X to Y not including X but including Y [X..Y] windows from X to Y including X and Y * EnterNotify(Virtual, B) means EnterNotify Event, detail Virtual, child = B. * * Pointer moves from A to B, nonlinear (CoreEnterLeaveNonLinear): * 1. a. if A has another pointer, goto 2. The goto seems correct -- nothing changes for A or any inferior of A. *b. otherwise, if A has a inferior with a pointer in it, * LeaveNotify(Inferior) to A This seems correct -- A sees the pointer move from A to inferior(A). * LeaveNotify(Virtual) between A and inferior(A) This seems wrong -- (A..inferior(A)) see the pointer remain in inferior(A). I'd say that no event should be generated here. In particular, LeaveNotify(Virtual) means that the focus is moving to an ancestor (of A). * 2. Find common ancestor X between A and B. * 3. Find closest pointer window P between A and X. *a. if P exists * LeaveNotify(Ancestor) to A This seems incomplete. If inferior(A) has a pointer, then A should see that pointer through a LeaveNotify(Inferior) event (already delivered above). Otherwise, A sees P's pointer. * LeaveNotify(Virtual) between A and P Again, this is incomplete -- if inferior(A) has a pointer, (A..P) should see that pointer and receive no events. Note that parent(A) should receive LeaveNotify(Virtual,A). *b. otherwise, if P does not exist, * LeaveNotify(NonLinear) to A Incomplete -- if inferior(A) has a pointer, A should see it and will have received a LeaveNotify(Inferior) above. * LeaveNotify(NonLinearVirtual) between A and X. Incomplete -- if inferior(A) has a pointer, then (A..X) should see it. X will also see other pointers, so precisely which windows X believes holds the pointer is a matter of pointer priority. Note that parent(A) should receive LeaveNotify(NonLinear, A). * 4. If X does not have a pointer, EnterNotify(NonLinearVirtual, B) to X. This seems wrong -- X shouldn't receive any event (This is window C in the non-linear case described in the protocol spec). * 5. Find closest pointer window Q between X and B. *a. if Q exists, EnterNotify(NonLinearVirtual) between X and Q I think this is incorrect; (X..Q] continue to see the pointer in Q and should receive no events. If B and inferior(B) do not contain a pointer, then (Q..B] see the pointer move from Q to B and should receive EnterNotify(Virtual) events, parent(B) should receive EnterNotify(Virtual,B) and B should receive EnterNotify(Ancestor). If B or inferior(b) do contain a pointer, then (Q..B] see the pointer move from inferior(B) to B. (Q..B) receive no events, while B receives an EnterNotify(Inferior). If inferior(B) is a child of B, then B receives EnterNotify(Inferior,inferior(B)) instead. *b. otherwise, EnterNotify(NonLinearVirtual) between X and B This is correct if B and inferior(B) do not contain a pointer. Note that parent(B) gets the child field set to B. If B or inferior(B) do contain a pointer, then (X..B) get no events. * 5. a. if B has another pointer in it, finish. Yup. *b. otherwise, if B has a inferior with a pointer in it * LeaveNotify(Virtual) between inferior(B) and B. Again, I think this is a mistake; LeaveNotify(Virtual) means the pointer is moving past the window to an ancestor. In this case, the pointer isn't moving at all as these windows see the pointer in inferior(B). * EnterNotify(Inferior) to B. Yes. *c. otherwise, EnterNotify(NonLinear) to B. Incomplete -- if Q exists, then B receives EnterNotify(Ancestor) instead. (why did you do the non-linear case first? It's the hardest...) * -- * * Pointer moves from A to B, A is an ancestor of B (CoreEnterLeaveToDescendant): * 1. a. If A has another pointer, goto 2. yes. *b. Otherwise, LeaveNotify(Inferior) to A. yes. * 2. Find
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 mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/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 drivers start exposing the standard names. I'd have no issues with adding a non-advocated EDID_DATA again to the server, if that sounds fit reasonable. Keith? I'd not encourage non-standard property names for things which we have standard properties for, that only encourages confusion. -- keith.pack...@intel.com signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [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 signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
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 ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
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 buttons, XI allows for more. That's a common misunderstanding -- the core protocol allows for up to 255 buttons, and the documentation for GrabButton is fairly clear about waiting until *all* buttons are released, not just the five visible in the mask. I think this makes the solution fairly easy, right? -- keith.pack...@intel.com signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [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 Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
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. I'd like to add floats to the render protocol as well, mostly for matrices where fixed point values cause significant errors. -- keith.pack...@intel.com signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [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': # 1920x1080 59.93 Hz (CVT 2.07M9-R) hsync: 66.59 kHz; pclk: 138.50 MHz Modeline 1920x1080R 138.50 1920 1968 2000 2080 1080 1083 1088 +hsync -vsync This is within the clock limits of a single link DVI or HDMI connection and should work a lot better. -- keith.pack...@intel.com signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: 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 changed since I was fluent writing config files, it seems... iow I didn't get it to work...) I've built patches which automatically reallocate the frame buffer as needed; they should be available after 2.6 ships. -- keith.pack...@intel.com signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [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 has bugs remaining, this sequence looks like the right approach to make this problem tractable. Please push this to master and I'll work on pulling it into the 1.6 branch, reviewing it as best I can in the process of doing that. -- keith.pack...@intel.com signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [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 condition I see here is: xf86CrtcRotate (with transform) allocates rotation_damage wraps block handler pScreen-BlockHandler == xf86RotateBlockHandler xf86_config-BlockHandler = (other block handler) xf86CrtcRotate (without transform) frees rotation_damage pScreen-BlockHandler == xf86RotateBlockHandler xf86_config-BlockHandler = (other block handler) (note lack of xf86RotateBlockHandler call here) xf86CrtcRotate (with transform) allocates rotation_damage wraps block handler xf86_config-BlockHandler = pScreen-BlockHandler Note that this makes xf86-BlockHandler == xf86RotateBlockHandler, causing a loop as the block handler attempts to unhook itself from the block handler chain. xf86RotateBlockHandler pScreen-BlockHandler = xf86RotateBlockHandler (and recurse, causing a stack overflow) -- keith.pack...@intel.com signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
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 ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
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 we ever send the physical region scanned by the CRTC, we should provide events that update it when panning occurs. Clients need to know about monitor geometry for two reasons: 1) Full-screen presentation mode. In this case, we want to fill the monitor, not the panning region. As such, we should report the monitor rectangle. 2) Full-screen web page mode. In this case, the user presumably specified a larger panning region precisely because some web page could not fit on the monitor. Reporting the monitor size will not help as the window manager will set the application size to fill that, and not fill the panning region. 3) Avoiding black holes in window placement. The window manager needs to make sure every window can be seen. In this case, we want to expose the panning region, not the monitor region. 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. Should this also extend to the meaning of the X/Y values in the RRSetCrtcConfig request? -- keith.pack...@intel.com signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
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 that to reduce the size of the diffs against the master versions of the files; otherwise there would be a large diff and merging future fixes would be harder. -- keith.pack...@intel.com signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: 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 anyone wants to write up some proposed protocol for XFixes, it would be easy to add the necessary code. I think this should more or less take the form of a DPMS grab, which I'm pretty sure we've discussed previously ... Yeah, we came up with a fairly simple mechanism here which involved events when clients disabled/enabled the screen saver -- the events would contain the current disable count. The screen saver application would *also* disable the automatic screen saver and then would be able to track other clients disable requests by noticing when the count 1. I don't think this requires any DPMS grabs, although a convention marking screens that have active screen saver applications might be helpful in avoiding multiple such applications. We were hoping to get per-CRTC DPMS stuff into RandR this server release cycle, but it didn't get finished up. That would give the screen saver application direct control over the monitor power states. I think, along with DPMS disable events, is sufficient to build a sensible external screen saver application. support for saner input focus semantics. it would be great if keyboard events always went to the window given to XSetInputFocus instead of possibly a child window thereof depending on the position of the mouse. xembed would thank you :) This seems like a fairly serious challenge given the core focus semantics. Delivering the events is probably easy enough to fix, but rewriting the focus-in/focus-out event code will probably cause whot to blow a gasket. -- keith.pack...@intel.com signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: 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 tell. Hm. Sounds logical. Still, the currently presented CRTC should be queryable. Yes, I agree. Perhaps we need an additional request for this? In the meantime, I'm thinking the existing request should return the panning bounds instead of the current CRTC bounds, and that we shouldn't send CrtcChangeNotify events when panning occurs. -- keith.pack...@intel.com signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: 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 are expected to query the server for the new hierarchy.
If clients need to take another round-trip, why pack any info into this
event other than the 'something changed' bit? Presumably this doesn't
happen very often, right?
Alternatively, pack the whole change into the event?
Classes is a list of input device classes that are now provided by the
device, see XI 1.x specification for more details.
Similarly, any reason to not just have the client download the new
device state after it receives this event?
A viable answer here might be that placing the data in events instead of
later replies is that clients can correctly parse the intervening event
stream. This doesn't apply to XDHCE events above as clients must query
state anyway.
root, event, child are the root window, event window or subwindow,
respectively. See core protocol spec for more detail.
root_x, root_y is the position of the pointer in screen coordinates
event_x, event_y is the position of the pointer in screen coordinates
relative to the event window.
Send these in floating point so we capture sub-pixel positions
trivially?
last_button is the highest bit set in buttons and determines the size of
buttons.
last_modifier is the highest bit set in modifiers and determines the size
of modifiers.
last_valuator is the highest bit set in valuators and determines the size
of valuators
Clients are likely to decode this incorrectly as you have to be careful
about all of these. Any reason to not just indicate the length of each
bit vector in 32-bit units?
axisvalues specifies the current value of the valuator in it's current
mode (relative or absolute).
I assume the native values for all devices are integers?
Relative Motion event.
type is XI_RelativeMotion
This event is sent regardless of clipping and always provides the
device-specific data. Pointer acceleration does not affect the axis
values.
Uh. What about absolute devices? Can those send XRelativeMotionEvents?
If so, this seems more like an XIDeviceRawEvent.
(same comments about last_* apply here)
┌───
XIPresence
GENERICEVENTDATA
devchange: SETofDEVICECHANGE
control:CARD16
└───
DEVICECHANGE { DeviceAdded, DeviceRemoved, DeviceEnabled, DeviceDisabled,
DeviceControlChanged }
DevicePresence event, equivalent to the XI 1.4 event.
type is XI_PresenceNotify
devchange specifies the type of device change that has occured. If
devchange is DeviceControlChanged, control specifies the ID of the device
control that has changed. Otherwise, control is unspecified.
The length of a Presence event is always 0.
How about describing this event in detail, rather than saying 'Like XI
1.4, except'. Keeping the XI 2 spec stand-alone would reduce the amount
of reading when learning how to do input.
- this isn't fixing the problem we have with devices that are both pointers
and keyboards
So make all devices both pointers and keyboards and have XIDeviceEvent
include keys as well as buttons.
- how do go about input classes. refurbish them?
I'm wondering whether input classes have any place now; just make all
devices the union of all classes?
- having 16 bit device ids requires to re-implement all requests and replies.
Use 32-bit device ids then.
Mostly just typing, but it has to be done.
- 32 bit keycodes is good but requires XKB2. I think. Daniel?
- still no subpixel precision, unless we decide to make the valuators 24.8, or
provide 32+32 or something.
16.16 is sufficient as X screens can't be larger than 16 bits anyway. Or
floats.
- am I heading down a dead end?
I don't think so; let's keep pushing towards eliminating weird
distinctions between devices and make sure we've got effectively two
kinds of events -- clipped and processed by the server, and raw device
events.
- is it beer o'clock yet?
Nothing related to X should have trouble finding a bar.
--
keith.pack...@intel.com
signature.asc
Description: This is a digitally signed message part
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: 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 kinda depends on how we expect to implement things on the client side. If we want to mirror the server device hierarchy in the client library, it might be easier to just take the 'something changed' event and reconstruct the whole client state than attempt to patch things with incremental data. Dunno. Not having this state makes us prone for race conditions. Class changes are expected to happen often, and a different XDCE may be generated while the request is waiting to be processed. In this case, the client cannot process events with the correct axis information. At least for XDCE, it is mandatory that the new information is part of the event. XDHCE is less frequent, justifying the query. Less frequent doesn't mean non-racy though; we've had this problem with X key mapping forever, and worse now that keymap notify events are happening more often. Send these in floating point so we capture sub-pixel positions trivially? ok. Or perhaps fixed point? That eliminates problems with different precision in different parts of the screen. Uh. What about absolute devices? Can those send XRelativeMotionEvents? If so, this seems more like an XIDeviceRawEvent. (same comments about last_* apply here) Good point. I will revise. Oh, are these INT32 here (for relative devices)? And, if so, do we use INT32 in the non-raw event for consistency? I don't have an answer for all that yet and it strikes me as one of those things that just need testing to see what works best. Ok, sounds like we need to figure out how grabs work for devices which are both pointer and keyboard then. I can't, frankly, think of a better way than having them appear as two logical SDs. Which leaves us with slightly weird event delivery, but that seems better than complicated grab semantics? The main point of input classes in XI2 would be to specifiy capabilities in detail. Some of the input classes aren't particularly great for that so they could do with a redesign. Example here is the ValuatorInfo that only allows for a single state across all axes. With the above discussion, it seems like SDs are either 'pointer' or 'keyboard' devices, and beyond that, they've got a collection of keys or buttons/axes. Making sure the per-axis information isn't constrained by some global device information seems like a requirement here. Current deviceids are CARD8, so CARD32 would still require a reimplementation. Now, at least for XI2 this may not be a problem as we could decide the upper 24 bit as reserved for future use and continue to only use 8 bits in requests and replies - until those are reimplemented at a later point in time. I guess I don't see any huge 're-implementation' here -- you're just widening a data type. It may cause a flag-day for input devices, but we've been there before. 16 bit ids were chosen mainly because the fit nicely after the event type in the GenericEvent. Before we run out of 2^16 deviceids per X server, we run into other issues anyway. Ok, seems fairly reasonable. XI valuators are already 32 bits, and we probably shouldn't scale down. we accept integer-only format in the valuator Right, so we use 16.16 fixed point for their screen coordinates then and get plenty of sub-pixel position. Another thing discussed briefly was the use of a separate format internal to the server, i.e. the XI events are assembled at delivery time, not carried through the server. This is an implementation detail though and shouldn't be too hard to support. Hmm. With the generic event stuff fixing the list-of-events disaster, is there some other format you'd prefer? Adding a gratuitous data type doesn't seem like a winning plan here. -- keith.pack...@intel.com signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: 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 1.6 ships. I posted a proposed patch to bug 19337; please give that a try and see if it fixes the bug for you. Then fix the driver to support RandR 1.2. -- keith.pack...@intel.com signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: 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 drawing to an upright frame buffer and then copying that to the rotated frame buffer for presentation. That's a lot of pixels to copy around each frame. Do you think the 945 chipset is just too slow to rotate a 1920x1200 screen? You're fairly seriously memory bandwidth limited with that chipset, and at that resolution. One thing that may improve performance a bit is when we get tiling support for the displayed buffer. That work requires some additional kernel infrastructure to manage the 'fence' registers which are responsible for linearizing tiled regions for software rendering code. You might try 16bpp instead of 32bpp; it won't look as good, but it should go faster. -- keith.pack...@intel.com signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: 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 proposed will work, so some feedback would be appreciated. I'd like to keep old drivers working as long as possible, but that's going to require continued testing by people who have hardware that uses them. -- keith.pack...@intel.com signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: 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 how to find a file in the source include directory as dix-config.h is in the build include directory. What would you like for a filename? Is dix-config-post.h sufficient? I wanted to keep dix-config in the name to make it obvious... Yeah, that sounds fine. You sure there's no way to leave this unmolested in dix-config.h? -- keith.pack...@intel.com signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: 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: dix-config-post.h No, there shouldn't be any reason to copy header files around, and lots of reasons not to. Just messing with suitable INCLUDE directives should work eventually. -- keith.pack...@intel.com signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [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) after using 3d for ~2-3 mins (with wine even faster :)) Eric and I found some rather significant 915/945 X/3D interaction problems yesterday that were leading to hardware lockups. He's hoping to finish up some fixes for that today. The core issue was that with DRI2, there isn't any hardware lock that the X server holds between batch buffers, so the 2D drawing code needs to be more careful about keeping setup code and the associated rendering code in the same batch buffer. -- keith.pack...@intel.com signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: 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 the real physical resolution 1920x1080. Yeah, the 1920x1080 resolution is probably in some CEA EDID block, which we aren't parsing yet (the EDID parsing code lives in the X server, btw). I think there's a patch around that adds more EDID parsing stuff. Until the X server gets this code, you can add the right mode line to your xorg.conf file, I'm betting a 1920x1080 reduced blanking mode will work just fine (using 'cvt -r 1920 1080'): # 1920x1080 59.93 Hz (CVT 2.07M9-R) hsync: 66.59 kHz; pclk: 138.50 MHz Modeline 1920x1080R 138.50 1920 1968 2000 2080 1080 1083 1088 +hsync -vsync Yeah, it's a pain, and yeah, I hope to see this code added to the X server soon. -- keith.pack...@intel.com signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
