Re: [xkb] Re: xkeyboard-config 1.9
Agree. Is there existing release.sh - or will I create one (and share as template)? I know, it is just 2-3 lines... (except for the message body) Sergey On Wed, Jun 16, 2010 at 11:59 PM, Peter Hutterer peter.hutte...@who-t.net wrote: On Wed, Jun 16, 2010 at 11:40:32PM +0100, Sergey Udaltsov wrote: First of all, I do not have permission to store anything there: $ ls -la /srv/xorg.freedesktop.org/archive/individual/data/xkeyboard-config total 16 drwxrwxr-x+ 2 root root 4096 2010-06-16 06:23 . drwxrwxr-x+ 3 kem xorg 4096 2010-06-16 06:23 .. Daniel, could you please check? I do not like the idea of announce emails to be autogenerated. Yes, scp/git tagging could(should) be automated. fwiw, the email is only autogenerated, not automatically sent. once you run the release script, it drops a tagname.announce file in the current directory and you can then use this as your announce email. Cheers, Peter On Wed, Jun 16, 2010 at 11:33 PM, Peter Hutterer peter.hutte...@who-t.net wrote: On Wed, Jun 16, 2010 at 03:24:19PM +0100, Sergey Udaltsov wrote: Thanks, I will use that space Sergey On 16 Jun 2010 14:33, Daniel Stone dan...@fooishbar.org wrote: On Wed, Jun 16, 2010 at 02:03:57PM +0100, Sergey Udaltsov wrote: I think that would be handy, thanks. Cool. annarchy.freedesktop.org:/srv/ xorg.freedesktop.org/archive/individual/data/xkeyboard-config/ ... might be worth putting the required bits into release.sh as well. Running a shell script that does everything for you is probably easier than generating everything by hand. end result for you would be you'd just run $ release.sh xkeyboard-config v1_9 v1_10 and the announce email, tag pushing, tarballs copying, etc. is all done for you. Cheers, Peter ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
RE: Rendering in geode
Morton, From your explanation and my test with rendercheck, I found it more complex for the driver to handle these special condition. Give the results I tested PictOpOver with the following XRenderComposite() call in Xlib app on ATI X1200. 1)XRenderComposite(dpy, PictOpOver, picture_10x10[0].pict, 0, win-pict, 11, 0, 0, 0, 50, 50, 30, 30) with the picture_10x10 has repeat attribute. Result: 30x30 rendering region 2) XRenderComposite(dpy, PictOpOver, picture_10x10[0].pict, 0, win-pict, 11, 0, 0, 0, 50, 50, 30, 30) with the picture_10x10 has no repeat attribute. Result: no-op 3) XRenderComposite(dpy, PictOpOver, picture_10x10[0].pict, 0, win-pict, -10, 0, 0, 0, 50, 50, 30, 30) with the picture_10x10 has repeat attribute.(negative coordinate) Result: 30x30 rendering region 4) XRenderComposite(dpy, PictOpOver, picture_10x10[0].pict, 0, win-pict, -10, 0, 0, 0, 50, 50, 30, 30) with the picture_10x10 has no repeat attribute.(negative coordinate) Result: 10x10 rendering region Just as you told me in the mail, the source coordinate is allowed to be outside of the image--positive and negative. In 1)-4), I gave the both tested, you can see the result. That is only the PictOpOver, I gave a test to PictOpSrc. The result is as you said, black region with no repeat parameter(zero vector). What I want to ask is that does driver need handle these all? I think it is a huge burden for the driver to judge. Why the server gave such parameters to driver? Maybe one of this special condition can make the driver rendering result fails, just as geode. And the most important thing is that, if the driver found it can not do that rendering, it is to late for put the rendering back to Xserver SW method. I can add some code to this special condition, but these questions above puzzle me. Thanks, Frank -Original Message- From: Jonathan Morton [mailto:jonathan.mor...@movial.com] Sent: 2010?6?14? 18:07 To: Huang, FrankR Cc: xorg-devel@lists.x.org; xorg-driver-ge...@lists.x.org Subject: RE: Rendering in geode On Sun, 2010-06-13 at 16:47 +0800, Huang, FrankR wrote: You know when the driver does the composite, it is called in exaTryDriverComposite() function. You guess what? It give a driver a composite call that the source's width is less than srcX. That is impossible from my point. Make is more simple: A XRenderComposite() call below: XRenderComposite(dpy, PictOpOver, picture_10x10[0].pict, 0, win-pict, 11, 0, 0, 0, 50, 50, 40, 40) The source is a 10x10 pixmap, but the srcX is 11. The rendering result is none! I think the driver should refuse that parameter to do the rendering. It will bring chaos operation. That is my thought. Source (and mask) coordinates are allowed to go outside the image involved - both positive and negative. The effect of this depends on the Repeat attribute on that image. If Repeat is None (0), then samples outside the image return the all-zeroes vector, even if the image doesn't have an alpha channel. This is then sent through the rendering equation as normal. If Repeat is Normal (1), then the coordinate is wrapped back into the image using the modulus (%) operation. This is your usual repeating tile function. As a special case, a 1x1 image with Repeat set to Normal is the usual way of representing a solid colour. Repeat values of Extend (2) and Mirror (3) are also possible. Obviously, you should reject attribute values that you cannot support. But it might happen that the hardware doesn't know how to do the None mode properly by itself, and failing to support that at CheckComposite time is pretty useless - but you don't know the coordinates until after that point. Let's suppose you support the Src and Over modes. These need to be handled differently if the coordinates can fall outside the source image(s) in No-Repeat mode: Src turns to a fill of the all-zeroes vector, and Over turns into a no-op. You can therefore divide the rendering area into normal and blanked zones, and issue separate commands to the hardware for each. Because Clear mode doesn't use the source or mask data at all, it is unaffected by this quirk - but it is rarely used. Other modes have similar simplifications as Src and Over. -- -- From: Jonathan Morton jonathan.mor...@movial.com ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
RE: Rendering in geode
Morton, I modify the geode driver on the condition 1). The bug is solved by applying the correct way. But I still need your answers for my questions below:). You give me great help:). Thanks, Frank -Original Message- From: Huang, FrankR Sent: 2010?6?17? 15:48 To: 'Jonathan Morton' Cc: xorg-devel@lists.x.org; xorg-driver-ge...@lists.x.org Subject: RE: Rendering in geode Morton, From your explanation and my test with rendercheck, I found it more complex for the driver to handle these special condition. Give the results I tested PictOpOver with the following XRenderComposite() call in Xlib app on ATI X1200. 1)XRenderComposite(dpy, PictOpOver, picture_10x10[0].pict, 0, win-pict, 11, 0, 0, 0, 50, 50, 30, 30) with the picture_10x10 has repeat attribute. Result: 30x30 rendering region 2) XRenderComposite(dpy, PictOpOver, picture_10x10[0].pict, 0, win-pict, 11, 0, 0, 0, 50, 50, 30, 30) with the picture_10x10 has no repeat attribute. Result: no-op 3) XRenderComposite(dpy, PictOpOver, picture_10x10[0].pict, 0, win-pict, -10, 0, 0, 0, 50, 50, 30, 30) with the picture_10x10 has repeat attribute.(negative coordinate) Result: 30x30 rendering region 4) XRenderComposite(dpy, PictOpOver, picture_10x10[0].pict, 0, win-pict, -10, 0, 0, 0, 50, 50, 30, 30) with the picture_10x10 has no repeat attribute.(negative coordinate) Result: 10x10 rendering region Just as you told me in the mail, the source coordinate is allowed to be outside of the image--positive and negative. In 1)-4), I gave the both tested, you can see the result. That is only the PictOpOver, I gave a test to PictOpSrc. The result is as you said, black region with no repeat parameter(zero vector). What I want to ask is that does driver need handle these all? I think it is a huge burden for the driver to judge. Why the server gave such parameters to driver? Maybe one of this special condition can make the driver rendering result fails, just as geode. And the most important thing is that, if the driver found it can not do that rendering, it is to late for put the rendering back to Xserver SW method. I can add some code to this special condition, but these questions above puzzle me. Thanks, Frank -Original Message- From: Jonathan Morton [mailto:jonathan.mor...@movial.com] Sent: 2010?6?14? 18:07 To: Huang, FrankR Cc: xorg-devel@lists.x.org; xorg-driver-ge...@lists.x.org Subject: RE: Rendering in geode On Sun, 2010-06-13 at 16:47 +0800, Huang, FrankR wrote: You know when the driver does the composite, it is called in exaTryDriverComposite() function. You guess what? It give a driver a composite call that the source's width is less than srcX. That is impossible from my point. Make is more simple: A XRenderComposite() call below: XRenderComposite(dpy, PictOpOver, picture_10x10[0].pict, 0, win-pict, 11, 0, 0, 0, 50, 50, 40, 40) The source is a 10x10 pixmap, but the srcX is 11. The rendering result is none! I think the driver should refuse that parameter to do the rendering. It will bring chaos operation. That is my thought. Source (and mask) coordinates are allowed to go outside the image involved - both positive and negative. The effect of this depends on the Repeat attribute on that image. If Repeat is None (0), then samples outside the image return the all-zeroes vector, even if the image doesn't have an alpha channel. This is then sent through the rendering equation as normal. If Repeat is Normal (1), then the coordinate is wrapped back into the image using the modulus (%) operation. This is your usual repeating tile function. As a special case, a 1x1 image with Repeat set to Normal is the usual way of representing a solid colour. Repeat values of Extend (2) and Mirror (3) are also possible. Obviously, you should reject attribute values that you cannot support. But it might happen that the hardware doesn't know how to do the None mode properly by itself, and failing to support that at CheckComposite time is pretty useless - but you don't know the coordinates until after that point. Let's suppose you support the Src and Over modes. These need to be handled differently if the coordinates can fall outside the source image(s) in No-Repeat mode: Src turns to a fill of the all-zeroes vector, and Over turns into a no-op. You can therefore divide the rendering area into normal and blanked zones, and issue separate commands to the hardware for each. Because Clear mode doesn't use the source or mask data at all, it is unaffected by this quirk - but it is rarely used. Other modes have similar simplifications as Src and Over. -- -- From: Jonathan Morton jonathan.mor...@movial.com ___ xorg-devel@lists.x.org: X.Org development Archives:
[PATCH 0/2] startup speed up by removing PCI routines
Hi. I'm sending again these two patches for review. I didn't change anything on both. Some discussions on the second happenend related with a better way to match video card lists. IMHO these are orthogonal with the current issue we are seeing here. If no one objects, I'd judge this as material for 1.9 release (even not being a bug fix). Please review. Thanks, Tiago Vignatti (2): xfree86: pci: remove superfluous vendor and card name logging xfree86: configure: remove vendor and card name matching rules hw/xfree86/common/xf86Configure.c | 23 --- hw/xfree86/common/xf86pciBus.c| 13 + 2 files changed, 1 insertions(+), 35 deletions(-) ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH 1/2] xfree86: pci: remove superfluous vendor and card name logging
X server suffers in startup time when relying on the pciaccess's linear search
to fetch vendor and video device name from PCI ID file (when existent). Such
names are only used to write the log, which may be superfluous. This
information often is provided by the drivers or likewise users can get the it
using external tools like lspci or scanpci.
This patch remove the references of those functions from X start up.
Reported-by: Richard Barnette jrbarne...@chromium.org
Signed-off-by: Tiago Vignatti tiago.vigna...@nokia.com
Tested-by: Richard Barnette jrbarne...@chromium.org
Reviewed-by: James Cloos cl...@jhcloos.com
---
hw/xfree86/common/xf86pciBus.c | 13 +
1 files changed, 1 insertions(+), 12 deletions(-)
diff --git a/hw/xfree86/common/xf86pciBus.c b/hw/xfree86/common/xf86pciBus.c
index 1517951..74016af 100644
--- a/hw/xfree86/common/xf86pciBus.c
+++ b/hw/xfree86/common/xf86pciBus.c
@@ -151,18 +151,13 @@ xf86PciProbe(void)
/* Print a summary of the video devices found */
for (k = 0; k num; k++) {
- const char *vendorname = NULL, *chipname = NULL;
const char *prim = ;
Bool memdone = FALSE, iodone = FALSE;
info = xf86PciVideoInfo[k];
- vendorname = pci_device_get_vendor_name( info );
- chipname = pci_device_get_device_name( info );
-
- if ((!vendorname || !chipname)
- !PCIALWAYSPRINTCLASSES(info-device_class))
+ if (!PCIALWAYSPRINTCLASSES(info-device_class))
continue;
if (xf86IsPrimaryPci(info))
@@ -173,12 +168,6 @@ xf86PciProbe(void)
info-vendor_id, info-device_id,
info-subvendor_id, info-subdevice_id);
- if (vendorname)
- xf86ErrorF(%s , vendorname);
-
- if (chipname)
- xf86ErrorF(%s , chipname);
-
xf86ErrorF(rev %d, info-revision);
for (i = 0; i 6; i++) {
--
1.7.1.226.g770c5
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH 0/2] startup speed up by removing PCI routines
Twas brillig at 15:22:39 17.06.2010 UTC+03 when tiago.vigna...@nokia.com did gyre and gimble: TV Tiago Vignatti (2): TV xfree86: pci: remove superfluous vendor and card name logging TV xfree86: configure: remove vendor and card name matching rules Reviewed-by: Mikhail Gusarov dotted...@dottedmag.net -- http://fossarchy.blogspot.com/ pgp09ELPAUKQS.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH evdev 0/3] Preliminary support of multitouch (rev4)
Peter Hutterer wrote: On Thu, Jun 10, 2010 at 05:47:57PM +0200, Benjamin Tissoires wrote: Even if there is an interesting thread concerning the use of multitouch on xorg-devel, I still send the up-to-date patches to enable multitouch as valuators. Changes since last time: * Remove the detection of the maximum number of touches based on the tracking ID * changes in comments Henrik, Rafi, others - any further comments on this? Patches look good to me, with a minor issue (see below) that can be fixed in a follow-up patch. Benjamin - I'm not sure exposing the tracking ID in a valuator is a good long-term solution. Does it provide any info that we do not already have by splitting the touchpoints into different valuators? Cheers, Peter Hi Peter, Benjamin, Carlos, I have a proposition to make, which might affect the Xevdev patchwork somewhat. Referencing our discussion in March, one major issue was how to resolve the kernel events into tracked contacts, before putting them onto the valuators. I think there is now a solution for it, which can be summarized as: 1. Extract the kernel events 2. Run them through the mtdev converter 3. Extract them as slotted type B events 4. Use the Valuators as slots Point 1 is all done, no problems there. The bulk of point 2 is also done, which may come as a surprise. Within a couple of days, there will be a git tree with a project called mtdev, which is a standalone converter module, under a free license (MIT/BSD/LGPL), which transforms all variants of kernel MT events to the slotted type B protocol. This means that for a device without finger tracking, the tracking is done in software. For devices with finger tracking, the data is simply transformed. For devices utilizing the new MT slots, the data goes straight through. Point is, by sending the events through mtdev, we gain a uniform source of MT events, which is compatible with the Valuator approach. This obviously affects the Xevdev code, point 3. However, the effect should be that the parsing code is simplified, since handling the MT slots is inherently easier than handling the type A protocol. Point 4 may or may not be different from what you all had in mind already. By using the valuators as regular MT slots, much of the ground work is already done. The protocol is documented, the process is simple, and there is a mechanism for dealing with adding/modifying/removing contacts. Comments are very much welcome. Cheers, Henrik ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH 0/2] startup speed up by removing PCI routines
On Thu, Jun 17, 2010 at 8:55 AM, Mikhail Gusarov dotted...@dottedmag.net wrote: Twas brillig at 15:22:39 17.06.2010 UTC+03 when tiago.vigna...@nokia.com did gyre and gimble: TV Tiago Vignatti (2): TV xfree86: pci: remove superfluous vendor and card name logging TV xfree86: configure: remove vendor and card name matching rules Reviewed-by: Mikhail Gusarov dotted...@dottedmag.net Reviewed-by: Alex Deucher alexdeuc...@gmail.com -- http://fossarchy.blogspot.com/ ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH 1/5] libXi: Fix usage of uninitialized value
On Mon, Jun 14, 2010 at 11:47:31 +0300, Pauli Nieminen wrote: In error case length of extra data could be uninitialized. This would result randomly sized request later in function. Signed-off-by: Pauli Nieminen ext-pauli.niemi...@nokia.com --- src/XIProperties.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/src/XIProperties.c b/src/XIProperties.c index 045cc71..0f77e58 100644 --- a/src/XIProperties.c +++ b/src/XIProperties.c @@ -150,6 +150,7 @@ XIChangeProperty(Display* dpy, int deviceid, Atom property, Atom type, default: /* BadValue will be generated */ ; +len = 0; } /* we use data instead of Data32 and friends to avoid Xlib's braindead Reviewed-by: Julien Cristau jcris...@debian.org Cheers, Julien ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH 2/5] libXi: Fix memory leak in XIGetSelectedEvents
On Mon, Jun 14, 2010 at 11:47:32 +0300, Pauli Nieminen wrote: mask_in was leaking for every successfull XIGetSelectedEvents. Signed-off-by: Pauli Nieminen ext-pauli.niemi...@nokia.com --- src/XISelEv.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/src/XISelEv.c b/src/XISelEv.c index bdc4fd1..3c1f018 100644 --- a/src/XISelEv.c +++ b/src/XISelEv.c @@ -161,6 +161,8 @@ XIGetSelectedEvents(Display* dpy, Window win, int *num_masks_return) *num_masks_return = reply.num_masks; +Xfree(mask_in); + return mask_out; error: Reviewed-by: Julien Cristau jcris...@debian.org Looks like this function also doesn't UnlockDisplay() on various paths? Cheers, Julien ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH 3/5] libXi: Use single error path in XQueryDeviceState
On Mon, Jun 14, 2010 at 11:47:33 +0300, Pauli Nieminen wrote: This reduces code duplication and fixes possible leak of data. data would leak if allocation of state fails. Signed-off-by: Pauli Nieminen ext-pauli.niemi...@nokia.com --- src/XQueryDv.c | 24 +--- 1 files changed, 9 insertions(+), 15 deletions(-) Reviewed-by: Julien Cristau jcris...@debian.org Cheers, Julien ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH 5/5] libXi: Use single error path in XGetDeviceControl
On Mon, Jun 14, 2010 at 11:47:35 +0300, Pauli Nieminen wrote:
This reduces code duplication and fixes possible leak of d. d would leak if
allocation of Device fails.
Signed-off-by: Pauli Nieminen ext-pauli.niemi...@nokia.com
---
src/XGetDCtl.c | 23 +--
1 files changed, 9 insertions(+), 14 deletions(-)
diff --git a/src/XGetDCtl.c b/src/XGetDCtl.c
index 8f76a51..729b0a0 100644
--- a/src/XGetDCtl.c
+++ b/src/XGetDCtl.c
@@ -84,19 +84,15 @@ XGetDeviceControl(
req-deviceid = dev-device_id;
req-control = control;
-if (!_XReply(dpy, (xReply *) rep, 0, xFalse)) {
- UnlockDisplay(dpy);
- SyncHandle();
- return (XDeviceControl *) NULL;
-}
+if (!_XReply(dpy, (xReply *) rep, 0, xFalse))
+ goto out;
+
if (rep.length 0) {
nbytes = (long)rep.length 2;
d = (xDeviceState *) Xmalloc((unsigned)nbytes);
if (!d) {
_XEatData(dpy, (unsigned long)nbytes);
- UnlockDisplay(dpy);
- SyncHandle();
- return (XDeviceControl *) NULL;
+ goto out;
}
sav = d;
_XRead(dpy, (char *)d, nbytes);
@@ -138,11 +134,9 @@ XGetDeviceControl(
}
Device = (XDeviceControl *) Xmalloc((unsigned)size);
- if (!Device) {
- UnlockDisplay(dpy);
- SyncHandle();
- return (XDeviceControl *) NULL;
- }
+ if (!Device)
+ goto out;
+
Sav = Device;
d = sav;
@@ -228,8 +222,9 @@ XGetDeviceControl(
default:
break;
}
- XFree(sav);
}
+out:
+XFree(sav);
UnlockDisplay(dpy);
SyncHandle();
Reviewed-by: Julien Cristau jcris...@debian.org
Cheers,
Julien
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: groff results in empty pngs (pnm* tools not on system)
On Wed, 2010-06-16 at 15:41 -0700, Dan Nicholson wrote: On Wed, Jun 16, 2010 at 3:24 PM, Julien Cristau jcris...@debian.org wrote: On Wed, Jun 16, 2010 at 15:00:10 -0700, Jeremy Huddleston wrote: The stderr from the above command shows a bunch of lines like: Calling `pnmcut 165 158 583 397 /var/folders/82/3fx+36+h6bh12wg5m +xpm4ymfn/T/groff-page-KcEGLl | pnmcrop -quiet | pnmtopng - background rgb:f/f/f -transparent rgb :f/f/f images/xim-image1.png ' returned status 32512 There is no pnmcut available on the system. Why are pnm* getting run by groff? Is that something that we (X11) have setup (and should therefore be checking in util-macros), or is that a dependency of groff which Mac OSX is not shipping (and I should therefore bug someone else). It looks like these utilities are needed by grohtml: DEPENDENCIES grohtml is dependent upon the png utilities (pnmcut, pnmcrop, pnmtopng) and GhostScript (gs). pnmtopng (version 2.37.6 or greater) and pnmcut from the netpbm package (version 9.16 or greater) will work also. It is also dependent upon psselect from the PSUtils package. Images are generated whenever a table, picture, equation or line is encountered. Yeah, I'm pretty sure this is all just fallout from -Thtml. Maybe we need to expand the XORG_WITH_GROFF macro to test that -Thtml works and export a HAVE_GROFF_HTML conditional. Then you could make the html targets in libX11/specs/troffrules.in conditional on that. Gaetan, you have any thoughts on groff html? I have noticed this issue when I reviewed the makefiles. Plus many other issues. And I got different results depending on the version of the tools. I personally have no experience with any of the doc tools. The only thing I did was to add the option to generate the images in the images directory and give them a name (-P-Dimages -P-Ixim-image) . Before, these images were given a name based on the process number and were accumulated for each run and never cleaned-up. I can update the macro to check for the presence of these commands, but probably not the version. That can't hurt. On my computer, they are all present. About one out of 5 images gets generated but they all look wrong. See attachment. -- Dan attachment: xim-image55.png signature.asc Description: This is a digitally signed message part ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH libXtst] specs: translate, format, process, install and distribute.
Makefile copied from libSM.
Signed-off-by: Gaetan Nadon mems...@videotron.ca
---
configure.ac |2 +
specs/.gitignore |8 ++
specs/Makefile.am | 80 +++-
specs/macros.t| 226 +
4 files changed, 315 insertions(+), 1 deletions(-)
create mode 100644 specs/.gitignore
create mode 100644 specs/macros.t
diff --git a/configure.ac b/configure.ac
index ded41dd..08ec061 100644
--- a/configure.ac
+++ b/configure.ac
@@ -32,7 +32,9 @@ m4_ifndef([XORG_MACROS_VERSION],
[m4_fatal([must install xorg-macros 1.6 or later before running
autoconf/autogen])])
XORG_MACROS_VERSION(1.6)
XORG_DEFAULT_OPTIONS
+XORG_ENABLE_SPECS
XORG_WITH_XMLTO(0.0.20)
+XORG_WITH_GROFF
AM_CONFIG_HEADER(config.h)
# Check for progs
diff --git a/specs/.gitignore b/specs/.gitignore
new file mode 100644
index 000..84d7456
--- /dev/null
+++ b/specs/.gitignore
@@ -0,0 +1,8 @@
+# Add Override for this directory and it's subdirectories
+*.html
+*.ps
+*.txt
+*.html.raw
+*.ps.raw
+*.txt.raw
+/images
diff --git a/specs/Makefile.am b/specs/Makefile.am
index a7e4709..74669fd 100644
--- a/specs/Makefile.am
+++ b/specs/Makefile.am
@@ -1 +1,79 @@
-EXTRA_DIST = recordlib.ms xtestlib.ms
+#
+# Copyright (c) 2010, Oracle and/or its affiliates. All rights reserved.
+#
+# Permission is hereby granted, free of charge, to any person obtaining a
+# copy of this software and associated documentation files (the Software),
+# to deal in the Software without restriction, including without limitation
+# the rights to use, copy, modify, merge, publish, distribute, sublicense,
+# and/or sell copies of the Software, and to permit persons to whom the
+# Software is furnished to do so, subject to the following conditions:
+#
+# The above copyright notice and this permission notice (including the next
+# paragraph) shall be included in all copies or substantial portions of the
+# Software.
+#
+# THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+# THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+# DEALINGS IN THE SOFTWARE.
+#
+
+EXTRA_DIST = macros.t recordlib.ms xtestlib.ms
+
+if ENABLE_SPECS
+if HAVE_GROFF_MS
+doc_DATA = recordlib.txt recordlib.ps recordlib.html xtestlib.txt xtestlib.ps
xtestlib.html
+imagesdir = $(docdir)/images
+
+CLEANFILES = $(doc_DATA)
+MOSTLYCLEANFILES = index.*
+
+install-data-local:
+ test -z $(imagesdir) || $(mkdir_p) $(DESTDIR)$(imagesdir)
+ @d=$(srcdir)/images/; \
+ list=`ls $$d`; \
+ for p in $$list; do \
+ echo $(INSTALL_DATA) '$$d$$p' '$(DESTDIR)$(imagesdir)/$$p'; \
+ $(INSTALL_DATA) $$d$$p $(DESTDIR)$(imagesdir)/$$p; \
+ done;
+
+uninstall-local:
+ @if test -n $(DESTDIR)$(imagesdir); then \
+ if test -d $(DESTDIR)$(imagesdir); then \
+ list=`ls $(DESTDIR)$(imagesdir)`; \
+ for p in $$list; do \
+ echo rm -f '$(DESTDIR)$(imagesdir)/$$p'; \
+ rm -f $(DESTDIR)$(imagesdir)/$$p; \
+ done \
+ fi; \
+ fi;
+
+mostlyclean-local:
+ @rm -fr images
+
+# Pass version string as a troff string for substitution
+GROFF_DEFS = -dxV=$(PACKAGE_STRING)
+
+# -t to run through tbl
+GROFF_FLAGS = -t -ms $(GROFF_DEFS) $(srcdir)/macros.t
+
+SUFFIXES = .ms .ps .txt .html
+
+.ms.ps:
+ -$(AM_V_GEN) $(GROFF) -Tps $(GROFF_FLAGS) $ 2 inde...@.raw $@
+ @if grep '^[^1-9.]' inde...@.raw | grep -v warning; then exit 1; \
+else test $$? -le 1; fi
+
+.ms.txt:
+ $(AM_V_GEN) env GROFF_NO_SGR=TRUE $(GROFF) -Tutf8 $(GROFF_FLAGS) \
+$ 2 inde...@.raw $@
+
+.ms.html:
+ $(AM_V_GEN) $(GROFF) -Thtml -P-Dimages -P-I$*-image $(GROFF_FLAGS) $
2 inde...@.raw $@
+
+endif HAVE_GROFF_MS
+endif ENABLE_SPECS
+
diff --git a/specs/macros.t b/specs/macros.t
new file mode 100644
index 000..cbc599b
--- /dev/null
+++ b/specs/macros.t
@@ -0,0 +1,226 @@
+.\ $Xorg: macros.t,v 1.3 2000/08/17 19:42:51 cpqbld Exp $
+.\ macros.t -- macros for X Consortium documents
+.\ Revised and commented by smarks 93.12.20.
+.\
+.\ global setup: set ragged right, assign string variables
+.\
+.na
+.ie n \{\
+.ds Q \
+.ds U \
+.ds - \%--
+.\}
+.el \{\
+.ds Q `\h'-\w'\^'u'`
+.ds U '\h'-\w'\^'u''
+.ds - \(em
+.\}
+.\
+.\ --- Ds --- displayed text (like .DS) with no keep
+.\ .Ds is obsolete. Change to something from this table:
+.\ for this use instead
+.\ .Ds.ID
+.\ .Ds n .LD (where n is a number)
+.\ (Numbers don't work in these macros, so .Ds 5
+.\ comes out the same as .Ds 0.)
+.\
+.de Ds
+.nf
+.\\$1D \\$2 \\$1
+.ft 1
+.ps \\n(PS
+.if \\n(VS=40 .vs
[PATCH libXext] specs: translate, format, process, install and distribute.
Makefile copied from libXtst
Remains to do are the Tex files.
Signed-off-by: Gaetan Nadon mems...@videotron.ca
---
configure.ac |2 +
specs/.gitignore |8 ++
specs/Makefile.am | 79 +++
specs/macros.t| 226 +
4 files changed, 315 insertions(+), 0 deletions(-)
create mode 100644 specs/.gitignore
create mode 100644 specs/macros.t
diff --git a/configure.ac b/configure.ac
index e132e0a..7847a71 100644
--- a/configure.ac
+++ b/configure.ac
@@ -17,6 +17,8 @@ m4_ifndef([XORG_MACROS_VERSION],
[m4_fatal([must install xorg-macros 1.3 or later before running
autoconf/autogen])])
XORG_MACROS_VERSION(1.3)
XORG_DEFAULT_OPTIONS
+XORG_ENABLE_SPECS
+XORG_WITH_GROFF
AM_CONFIG_HEADER([config.h])
# Determine .so library version per platform
diff --git a/specs/.gitignore b/specs/.gitignore
new file mode 100644
index 000..84d7456
--- /dev/null
+++ b/specs/.gitignore
@@ -0,0 +1,8 @@
+# Add Override for this directory and it's subdirectories
+*.html
+*.ps
+*.txt
+*.html.raw
+*.ps.raw
+*.txt.raw
+/images
diff --git a/specs/Makefile.am b/specs/Makefile.am
index a82d5a2..7d39c2a 100644
--- a/specs/Makefile.am
+++ b/specs/Makefile.am
@@ -1,5 +1,84 @@
+#
+# Copyright (c) 2010, Oracle and/or its affiliates. All rights reserved.
+#
+# Permission is hereby granted, free of charge, to any person obtaining a
+# copy of this software and associated documentation files (the Software),
+# to deal in the Software without restriction, including without limitation
+# the rights to use, copy, modify, merge, publish, distribute, sublicense,
+# and/or sell copies of the Software, and to permit persons to whom the
+# Software is furnished to do so, subject to the following conditions:
+#
+# The above copyright notice and this permission notice (including the next
+# paragraph) shall be included in all copies or substantial portions of the
+# Software.
+#
+# THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+# THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+# DEALINGS IN THE SOFTWARE.
+#
+
EXTRA_DIST = \
+ macros.t\
dbelib.tex \
DPMSLib.ms \
shapelib.ms \
synclib.tex
+
+if ENABLE_SPECS
+if HAVE_GROFF_MS
+doc_DATA = DPMSLib.txt DPMSLib.ps DPMSLib.html shapelib.txt shapelib.ps
shapelib.html
+imagesdir = $(docdir)/images
+
+CLEANFILES = $(doc_DATA)
+MOSTLYCLEANFILES = index.*
+
+install-data-local:
+ test -z $(imagesdir) || $(mkdir_p) $(DESTDIR)$(imagesdir)
+ @d=$(srcdir)/images/; \
+ list=`ls $$d`; \
+ for p in $$list; do \
+ echo $(INSTALL_DATA) '$$d$$p' '$(DESTDIR)$(imagesdir)/$$p'; \
+ $(INSTALL_DATA) $$d$$p $(DESTDIR)$(imagesdir)/$$p; \
+ done;
+
+uninstall-local:
+ @if test -n $(DESTDIR)$(imagesdir); then \
+ if test -d $(DESTDIR)$(imagesdir); then \
+ list=`ls $(DESTDIR)$(imagesdir)`; \
+ for p in $$list; do \
+ echo rm -f '$(DESTDIR)$(imagesdir)/$$p'; \
+ rm -f $(DESTDIR)$(imagesdir)/$$p; \
+ done \
+ fi; \
+ fi;
+
+mostlyclean-local:
+ @rm -fr images
+
+# Pass version string as a troff string for substitution
+GROFF_DEFS = -dxV=$(PACKAGE_STRING)
+
+# -t to run through tbl
+GROFF_FLAGS = -t -ms $(GROFF_DEFS) $(srcdir)/macros.t
+
+SUFFIXES = .ms .ps .txt .html
+
+.ms.ps:
+ -$(AM_V_GEN) $(GROFF) -Tps $(GROFF_FLAGS) $ 2 inde...@.raw $@
+ @if grep '^[^1-9.]' inde...@.raw | grep -v warning; then exit 1; \
+else test $$? -le 1; fi
+
+.ms.txt:
+ $(AM_V_GEN) env GROFF_NO_SGR=TRUE $(GROFF) -Tutf8 $(GROFF_FLAGS) \
+$ 2 inde...@.raw $@
+
+.ms.html:
+ $(AM_V_GEN) $(GROFF) -Thtml -P-Dimages -P-I$*-image $(GROFF_FLAGS) $
2 inde...@.raw $@
+
+endif HAVE_GROFF_MS
+endif ENABLE_SPECS
+
diff --git a/specs/macros.t b/specs/macros.t
new file mode 100644
index 000..cbc599b
--- /dev/null
+++ b/specs/macros.t
@@ -0,0 +1,226 @@
+.\ $Xorg: macros.t,v 1.3 2000/08/17 19:42:51 cpqbld Exp $
+.\ macros.t -- macros for X Consortium documents
+.\ Revised and commented by smarks 93.12.20.
+.\
+.\ global setup: set ragged right, assign string variables
+.\
+.na
+.ie n \{\
+.ds Q \
+.ds U \
+.ds - \%--
+.\}
+.el \{\
+.ds Q `\h'-\w'\^'u'`
+.ds U '\h'-\w'\^'u''
+.ds - \(em
+.\}
+.\
+.\ --- Ds --- displayed text (like .DS) with no keep
+.\ .Ds is obsolete. Change to something from this table:
+.\ for this use instead
+.\ .Ds.ID
+.\ .Ds n .LD (where n is a number)
+.\ (Numbers don't work in these macros, so .Ds 5
+.\ comes out the same
[PATCH] Addition to XFixes for cursor constraint
Hi, Attached are some patches which add a method of constraining the cursor to a given region (or rect, really). The reason I'd like to have this is to restrict the cursor to the visible area on an overscanned TV screen, though I suppose there may be other uses as well. The patches are against the version of Xorg in Ubuntu Lucid, but hopefully they'll apply easily to the current stuff. Thanks, James libxfixes_cursor_region_v1.diff Description: Binary data x11proto_fixes_cursor_region_v1.diff Description: Binary data xorg_server_xfixes_cursor_region_v1.diff Description: Binary data ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [xkb] Re: xkeyboard-config 1.9
Thanks, Daniel, it is ok now. I uploaded my files and they are available at http://xorg.freedesktop.org/releases/individual/data/xkeyboard-config/ Sergey On Thu, Jun 17, 2010 at 12:40 AM, Daniel Stone dan...@fooishbar.org wrote: On Wed, Jun 16, 2010 at 11:40:32PM +0100, Sergey Udaltsov wrote: First of all, I do not have permission to store anything there: $ ls -la /srv/xorg.freedesktop.org/archive/individual/data/xkeyboard-config total 16 drwxrwxr-x+ 2 root root 4096 2010-06-16 06:23 . drwxrwxr-x+ 3 kem xorg 4096 2010-06-16 06:23 .. Daniel, could you please check? Oops, sorry. Fixed. Cheers, Daniel -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkwZYPoACgkQUVYB1rKAgJRkdQCfdjBy9eBPq2iQJgvWrK1w60S2 zwYAn3EC0pauV8tRu814iZMSJnsTU7Xz =NyL6 -END PGP SIGNATURE- ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [xkb] Re: xkeyboard-config 1.9
Peter, Thanks for the link. Should I fix the script to incorporate xk-c (during the next release) or would you prefer to manage it yourself? Sergey On Thu, Jun 17, 2010 at 12:34 AM, Peter Hutterer peter.hutte...@who-t.net wrote: On Thu, Jun 17, 2010 at 12:02:17AM +0100, Sergey Udaltsov wrote: Agree. Is there existing release.sh - or will I create one (and share as template)? I know, it is just 2-3 lines... (except for the message body) http://cgit.freedesktop.org/xorg/util/modular/tree/release.sh that's what I meant with my first email, shouldn't be too hard to slot xkeyboard-config in there as a separate repo and that way you get to benefit from the rest of the bits in there that are already tested. Cheers, Peter On Wed, Jun 16, 2010 at 11:59 PM, Peter Hutterer peter.hutte...@who-t.net wrote: On Wed, Jun 16, 2010 at 11:40:32PM +0100, Sergey Udaltsov wrote: First of all, I do not have permission to store anything there: $ ls -la /srv/xorg.freedesktop.org/archive/individual/data/xkeyboard-config total 16 drwxrwxr-x+ 2 root root 4096 2010-06-16 06:23 . drwxrwxr-x+ 3 kem xorg 4096 2010-06-16 06:23 .. Daniel, could you please check? I do not like the idea of announce emails to be autogenerated. Yes, scp/git tagging could(should) be automated. fwiw, the email is only autogenerated, not automatically sent. once you run the release script, it drops a tagname.announce file in the current directory and you can then use this as your announce email. Cheers, Peter On Wed, Jun 16, 2010 at 11:33 PM, Peter Hutterer peter.hutte...@who-t.net wrote: On Wed, Jun 16, 2010 at 03:24:19PM +0100, Sergey Udaltsov wrote: Thanks, I will use that space Sergey On 16 Jun 2010 14:33, Daniel Stone dan...@fooishbar.org wrote: On Wed, Jun 16, 2010 at 02:03:57PM +0100, Sergey Udaltsov wrote: I think that would be handy, thanks. Cool. annarchy.freedesktop.org:/srv/ xorg.freedesktop.org/archive/individual/data/xkeyboard-config/ ... might be worth putting the required bits into release.sh as well. Running a shell script that does everything for you is probably easier than generating everything by hand. end result for you would be you'd just run $ release.sh xkeyboard-config v1_9 v1_10 and the announce email, tag pushing, tarballs copying, etc. is all done for you. Cheers, Peter ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: groff results in empty pngs (pnm* tools not on system)
On Wed, 2010-06-16 at 15:00 -0700, Jeremy Huddleston wrote: In the process of building libX11, I noticed that a ton of empty images are being created. The command that results in the empty images is: ~/src/freedesktop/src/libX11/specs/XIM (master) $ /usr/bin/groff -e -t -ms -dxV=libX11 1.3.4 -I. ../../specs/macros.t -Thtml -P-Dimages -P- Ixim-image xim.ms 2 index.xim.html.raw xim.html ~ $ ls -al /usr/X11/share/doc/libX11/specs/XIM/images/ total 0 drwxr-xr-x 61 root wheel 2074 Jun 16 12:15 . drwxr-xr-x 6 root wheel 204 Jun 16 12:15 .. -rw-r--r-- 1 root wheel0 Jun 16 11:48 xim-image1.png -rw-r--r-- 1 root wheel0 Jun 16 11:48 xim-image10.png ... The stderr from the above command shows a bunch of lines like: Calling `pnmcut 165 158 583 397 /var/folders/82/3fx+36+h6bh12wg5m +xpm4ymfn/T/groff-page-KcEGLl | pnmcrop -quiet | pnmtopng - background rgb:f/f/f -transparent rgb :f/f/f images/xim-image1.png ' returned status 32512 There is no pnmcut available on the system. Why are pnm* getting run by groff? Is that something that we (X11) have setup (and should therefore be checking in util-macros), or is that a dependency of groff which Mac OSX is not shipping (and I should therefore bug someone else). I'd like to know if the images get generated correctly. http://netpbm.darwinports.com/ signature.asc Description: This is a digitally signed message part ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
server-side xcb
I started looking into how to generate everything that has to do with the wire protocol using xcb. I'm starting small, with the easier extensions first (dpms), and I'll be gradually adding support for the more complicated extensions as the time goes. This mail serves as an overview of what I've been playing with in the past few days. The code is nowhere near functional, but should give you an idea into which direction I'm heading. Comments are very much appreciated. I took c_client.py as an inspiration how to generate the C source files. However, instead of doing that straight from python, I've chosen to use a templating engine. I couldn't find any for python that would be suitable to generate C, all engines focus mostly on html. So the template itself looks strange and emacs has troubles using the right syntax highlighting because it can't decide whether it's C, python or html. But overall I think a template is better than plain python. The code generates request/reply structures, corresponding swap functions and a function prefixed with wire_. That function is what's called by the dispatch code. The function validates the request size, swaps the request if necessary and then calls the function prefixed with impl_, that's where the actual implementation would be. If the request requires a reply, the impl_ function also fills the reply structure. The reply is optionally swapped and then sent to the client. So there is only one set of protocol handlers because they handle both swapped and non-swapped clients. You can look at the code for DPMS QueryVersion here: http://github.com/wereHamster/xorg-server/blob/server-side-xcb/proto/dpms.c#L9 The current code only works with requests/replies which use simple fields. Lists etc are not supported yet. One issue is how to represent (and swap) dynamically sized fields in the request/reply structures, another is how to give the client the ability to write additional data after the reply (as in GetImage for example). I'll take a look at how xcb solved these problems. tom ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] DRI2/xserver: Don't hang in glXSwapBuffers if drawable moves between crtc's
Hi Keith and Peter,
this patch has been reviewed by Jesse Barnes and now successfully
tested by the guy who submitted the bug report and by me. Fixes
Bugzilla bug #28383, a quite ugly hang of application windows
bufferswapping, including crashes when moving them between different
crtc's of different refresh rate.
It would be good to apply it to 1.9 and 1.8.2 if possible, for a more
enjoyable multi-display OpenGL experience.
thanks,
-mario
On Jun 14, 2010, at 6:13 PM, Jesse Barnes wrote:
On Sun, 13 Jun 2010 18:05:26 +0200
Mario Kleiner mario.klei...@tuebingen.mpg.de wrote:
Detect if a drawable has been moved from an original crtc to a new
crtc
with a lower current vblank count than the original crtc inbetween
glXSwapBuffers() calls. Reinitialize drawable's last_swap_target
before scheduling next swap if such a move has taken place.
last_swap_target defines the baseline for scheduling the next swap.
If a movement between crtc's is not taken into account, the swap may
schedule for a vblank count on the new crtc far in the future,
resulting
in a apparent hang of the drawable for a long time.
Fixes Bugzilla bug #28383.
Signed-off-by: Mario Kleiner mario.klei...@tuebingen.mpg.de
---
hw/xfree86/dri2/dri2.c | 15 +++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/hw/xfree86/dri2/dri2.c b/hw/xfree86/dri2/dri2.c
index d33b0d1..1f80022 100644
--- a/hw/xfree86/dri2/dri2.c
+++ b/hw/xfree86/dri2/dri2.c
@@ -756,6 +756,7 @@ DRI2SwapBuffers(ClientPtr client, DrawablePtr
pDraw, CARD64 target_msc,
DRI2DrawablePtr pPriv;
DRI2BufferPtr pDestBuffer = NULL, pSrcBuffer = NULL;
int ret, i;
+CARD64 ust, current_msc;
pPriv = DRI2GetDrawable(pDraw);
if (pPriv == NULL) {
@@ -800,12 +801,26 @@ DRI2SwapBuffers(ClientPtr client,
DrawablePtr pDraw, CARD64 target_msc,
* need to schedule a swap for the last swap target + the
swap interval.
*/
if (target_msc == 0 divisor == 0 remainder == 0) {
+ /* If the current vblank count of the drawable's crtc is lower
+* than the count stored in last_swap_target from a previous swap
+* then reinitialize last_swap_target to the current crtc's msc,
+* otherwise the swap will hang. This will happen if the drawable
+ * is moved to a crtc with a lower refresh rate, or a crtc that
just
+* got enabled.
+*/
+ if (!(*ds-GetMSC)(pDraw, ust, current_msc))
+ pPriv-last_swap_target = 0;
+
+ if (current_msc pPriv-last_swap_target)
+ pPriv-last_swap_target = current_msc;
+
/*
* Swap target for this swap is last swap target + swap interval
since
* we have to account for the current swap count, interval, and the
* number of pending swaps.
*/
*swap_target = pPriv-last_swap_target + pPriv-swap_interval;
+
} else {
/* glXSwapBuffersMscOML could have a 0 target_msc, honor it */
*swap_target = target_msc;
Yeah, this looks ok. Really we should write up GLX extension that
clarifies behavior in multi-head and display on/off situations
too. Is
that something you could do?
Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org
--
Jesse Barnes, Intel Open Source Technology Center
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH] Addition to XFixes for cursor constraint
Hi, Attached are some patches which add a method of constraining the cursor to a given region (or rect, really). The reason I'd like to have this is to restrict the cursor to the visible area on an overscanned TV screen, though I suppose there may be other uses as well. The patches are against the version of Xorg in Ubuntu Lucid, but hopefully they'll apply easily to the current stuff. Thanks, James libxfixes_cursor_region_v1.diff Description: Binary data x11proto_fixes_cursor_region_v1.diff Description: Binary data xorg_server_xfixes_cursor_region_v1.diff Description: Binary data ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] Addition to XFixes for cursor constraint
On 06/17/2010 09:46 PM, James Willcox wrote: Hi, Attached are some patches which add a method of constraining the cursor to a given region (or rect, really). The reason I'd like to have this is to restrict the cursor to the visible area on an overscanned TV screen, though I suppose there may be other uses as well. The patches are against the version of Xorg in Ubuntu Lucid, but hopefully they'll apply easily to the current stuff. Might it be the right way to finally solve this bug? https://bugs.freedesktop.org/show_bug.cgi?id=20334 Adam signature.asc Description: OpenPGP digital signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] DRI2/xserver: Don't hang in glXSwapBuffers if drawable moves between crtc's
On Fri, Jun 18, 2010 at 03:22:53AM +0200, Mario Kleiner wrote: Hi Keith and Peter, this patch has been reviewed by Jesse Barnes and now successfully tested by the guy who submitted the bug report and by me. Fixes Bugzilla bug #28383, a quite ugly hang of application windows bufferswapping, including crashes when moving them between different crtc's of different refresh rate. It would be good to apply it to 1.9 and 1.8.2 if possible, for a more enjoyable multi-display OpenGL experience. It's on my list, I'm just waiting for it to land on master. Cheers, Peter ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: Attach touch screen to a single display
There is no problem about having a single large desktop... but I need to use nvidia driver and as far as I understand it does not support Rand1.2. The race condition is caused because xf86InputSetScreen is not thread safe? About Peter Korsgaard matrix... where can I found it to take a look? Thanks. On Wed, Jun 16, 2010 at 3:21 AM, Peter Hutterer peter.hutte...@who-t.netwrote: On Mon, Jun 14, 2010 at 05:10:40PM +0200, Julian Ortiz wrote: Hello, After looking for a way to make a touch screen works only in its display (with nvidia configured as different XScreens) with no luck at all, I started to look at the input modules source. I realizes that the proprietary elo module calls to xf86XInputSetScreen, the function name seems promising, so I just patch the evdev module to support several screens by configuration and to call xf86InputSetScreen in the EvdevReadInput just before the EvdevProcessEvent. The result seems to work but the behavior is very erratic and sometimes the mouse/touch/keyboard get freezes and I need to restart X. And more strange, after launch several OpenGL application the performance drops so, so much (obviously without the patch it doesn't happen) Is xf86InputSetScreen the best approach to handle this? There's a race condition that can be triggered by xf86InputSetScreen() that ends up with a cursor jumping indefinitely between the two screens. This is likely the freeze you're seeing. There's unfortunately no good way to bind the device to a single screen right now. Peter Korsgaard input transformation matrix allows it for a RandR 1.2 setup but not for multiple protocol screens. Cheers, Peter Trying to find the module responsible for the mouse switch between different display I saw references to something called SilkenMouse, but I can't find any documentation about what is this. Any idea? ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH evdev 0/3] Preliminary support of multitouch (rev4)
On Thu, Jun 17, 2010 at 11:51:34AM -0400, Chase Douglas wrote: On Thu, 2010-06-17 at 12:16 +1000, Peter Hutterer wrote: On Thu, Jun 10, 2010 at 05:47:57PM +0200, Benjamin Tissoires wrote: Even if there is an interesting thread concerning the use of multitouch on xorg-devel, I still send the up-to-date patches to enable multitouch as valuators. Changes since last time: * Remove the detection of the maximum number of touches based on the tracking ID * changes in comments Henrik, Rafi, others - any further comments on this? Patches look good to me, with a minor issue (see below) that can be fixed in a follow-up patch. From patch 2/3: +#define ABS_MT_X_VALUE 0x8 +#define ABS_MT_Y_VALUE 0x16 It looks like ABS_MT_Y_VALUE should be 0x10. :) Overall this makes sense to me for devices where the MT data should be attached to the cursor (i.e. like a magicmouse). How will this mesh with direct input devices (or whatever mechanism is developed for multitouch touchscreens)? It seems to me we will need to somehow tell the module whether to pass the data as valuators or as DIDs, but not both. However, that's an implementation detail that can be worked out later when we get to it. Benjamin - I'm not sure exposing the tracking ID in a valuator is a good long-term solution. Does it provide any info that we do not already have by splitting the touchpoints into different valuators? Why not expose the tracking ID? It's one less thing for the client to worry about if it needs to track touches. Without the ID, clients would have to implement their own tracking algorithms because they would just get an array of touches. The same finger will be sent in a different slot of the array on subsequent events, such as when a previous finger is removed. -- Chase I believe the argument against is that the valuators already carry that information implicitly (eg axis 12 would be Y of the third contact and would continue in that role even if there are no active contacts 1 and 2). As such having another valuator would be wasteful. On the other hand, some devices carry a tiny be of extra information through the specific contact id's, and they are not strictly the lowest set of numbers needed to express the contacts that are active or have been activated since the last period of inactivity. From what I've heard the magic mouse (again) is one such example. I haven't actually poked around enough to see it. Personally I haven't yet come up with or heard an argument for caring about the real tracking id values and every usage case I've come up with, it would seem just as easily served computing it from in the client. However, I also know that I'm insufficiently creative to eliminate the possibility that someone else would have a good reason down the line. Would it make sense to leave it as an option? I'd like to see these patches accepted. Like Chase, I'm concerned how this will interact with the DID discussion. Would it make sense to apply it in a branch at very least so Ben doesn't have to continualy maintain the changes while the discussion rolls on. rafi ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH evdev 0/3] Preliminary support of multitouch (rev4)
On Fri, Jun 18, 2010 at 12:18:00AM -0400, Rafi Rubin wrote: On Thu, Jun 17, 2010 at 11:51:34AM -0400, Chase Douglas wrote: On Thu, 2010-06-17 at 12:16 +1000, Peter Hutterer wrote: On Thu, Jun 10, 2010 at 05:47:57PM +0200, Benjamin Tissoires wrote: Even if there is an interesting thread concerning the use of multitouch on xorg-devel, I still send the up-to-date patches to enable multitouch as valuators. Changes since last time: * Remove the detection of the maximum number of touches based on the tracking ID * changes in comments Henrik, Rafi, others - any further comments on this? Patches look good to me, with a minor issue (see below) that can be fixed in a follow-up patch. From patch 2/3: +#define ABS_MT_X_VALUE 0x8 +#define ABS_MT_Y_VALUE 0x16 It looks like ABS_MT_Y_VALUE should be 0x10. :) Overall this makes sense to me for devices where the MT data should be attached to the cursor (i.e. like a magicmouse). How will this mesh with direct input devices (or whatever mechanism is developed for multitouch touchscreens)? It seems to me we will need to somehow tell the module whether to pass the data as valuators or as DIDs, but not both. However, that's an implementation detail that can be worked out later when we get to it. Benjamin - I'm not sure exposing the tracking ID in a valuator is a good long-term solution. Does it provide any info that we do not already have by splitting the touchpoints into different valuators? Why not expose the tracking ID? It's one less thing for the client to worry about if it needs to track touches. Without the ID, clients would have to implement their own tracking algorithms because they would just get an array of touches. The same finger will be sent in a different slot of the array on subsequent events, such as when a previous finger is removed. -- Chase I believe the argument against is that the valuators already carry that information implicitly (eg axis 12 would be Y of the third contact and would continue in that role even if there are no active contacts 1 and 2). As such having another valuator would be wasteful. yeah, it's superfluous and imo sending what is essentially an ID down an axis seems a bit odd at best. It's akin to sending a button number down as an axis. On the other hand, some devices carry a tiny be of extra information through the specific contact id's, and they are not strictly the lowest set of numbers needed to express the contacts that are active or have been activated since the last period of inactivity. From what I've heard the magic mouse (again) is one such example. I haven't actually poked around enough to see it. do you have any info on what this extra information could be? Personally I haven't yet come up with or heard an argument for caring about the real tracking id values and every usage case I've come up with, it would seem just as easily served computing it from in the client. However, I also know that I'm insufficiently creative to eliminate the possibility that someone else would have a good reason down the line. Would it make sense to leave it as an option? I'd like to see these patches accepted. Like Chase, I'm concerned how this will interact with the DID discussion. Would it make sense to apply it in a branch at very least so Ben doesn't have to continualy maintain the changes while the discussion rolls on. I expect it to provide some useful information once people start playing with it. It may not be the final approach but meanwhile, any info we can get on how we can handle input better is useful. Besides, the DID implementaion is quite a bit off, as far as I can tell. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
