PATH for EDID vendor VSC, prod id 19227
Hi , If the ViewSonic display (EDID vendor VSC, prod id 19227) is changed to low than 1280x1024 ( 800x600, 640x480, 1024x768), there are 2 black borders on the top and bottom of the screen, while resolution with 1280x1024 works fine. Because the display don't support vertical fresh over 75, the patch avoid the problem by appending quirk. Thanks Ma Ling xf86EdidModes.patch Description: xf86EdidModes.patch ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Extra pointer motion with current git xf86-input-synaptics
On Sunday 28 September 2008, Peter Hutterer wrote: On Sat, Sep 27, 2008 at 06:10:32PM +0100, Magnus Kessler wrote: Since updating to the current git version of xorg-server, inputproto and xf86-input-synaptics I observe extra pointer movements for every event generated by the touchpad. Even when not touching the pad and using the buttons instead the pointer moves 1 pixel to the top-left which each event (x and y coordinate decrease by 1 every time). Equally, each event generated from touching the pad seems to have this extra movement towards the top-left of the screen. what hardware do you have? Any special options in xorg.conf/the fdi file? Cheers, Peter This is with an external mini-keyboard with built-in touchpad. Dmesg reports it as Synaptics Touchpad, model: 1, fw: 4.1, id: 0x14aa1, caps: 0x0/0x0 and in Xorg.0.log the xf86-input-synaptics driver reports (**) Option Device /dev/input/event1 (II) SynPS/2 Synaptics TouchPad: x-axis range 1472 - 5472 (II) SynPS/2 Synaptics TouchPad: y-axis range 1408 - 4448 (II) SynPS/2 Synaptics TouchPad: pressure range 0 - 255 (II) SynPS/2 Synaptics TouchPad: finger width range 0 - 0 (II) SynPS/2 Synaptics TouchPad: buttons: left right middle double triple (**) Option SHMConfig 1 (**) Option VertEdgeScroll 1 (**) Option HorizEdgeScroll 1 (**) Option LockedDrags 0 (**) Option TapButton1 1 (**) Option PalmDetect yes The fdi file I'm using is ?xml version=1.0 encoding=ISO-8859-1? deviceinfo version=0.2 device match key=info.capabilities contains=input.touchpad match key=info.product contains=Synaptics TouchPad merge key=input.x11_driver type=stringsynaptics/merge merge key=input.x11_options.Emulate3Buttons type=stringyes/merge merge key=input.x11_options.LockedDrags type=string0/merge merge key=input.x11_options.PalmDetect type=stringyes/merge merge key=input.x11_options.CoastingSpeed type=string20/merge merge key=input.x11_options.TapButton1 type=string1/merge merge key=input.x11_options.VertEdgeScroll type=string1/merge merge key=input.x11_options.HorizEdgeScroll type=string1/merge merge key=input.x11_options.SHMConfig type=string1/merge /match /match /device /deviceinfo I have just reverted the part of commit c405a69f83dab77cfe6c76f718a3ca5614a85918 that passes the actual x/y ranges to xf86InitValuatorAxisStruct. Now the extra movement is gone, but I get a somewhat quicker cursor movement than I was used to before. This would be due to the other recent changes that set new default values for the acceleration parameters, of course. I'm trying to see where in the valuators are actually used inside the X server. With a smaller range than [0, -1] some rounding error (?) seems to create that extra pixel offset for each event processed. This is on a 64-bit platform, in case this is important. Any hints on where to look next are welcome. Cheers, Magnus 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: Extra pointer motion with current git xf86-input-synaptics
On Sun, Sep 28, 2008 at 08:23:51AM +0100, Magnus Kessler wrote: I have just reverted the part of commit c405a69f83dab77cfe6c76f718a3ca5614a85918 that passes the actual x/y ranges to xf86InitValuatorAxisStruct. Now the extra movement is gone, but I get a somewhat quicker cursor movement than I was used to before. This would be due to the other recent changes that set new default values for the acceleration parameters, of course. I'm trying to see where in the valuators are actually used inside the X server. With a smaller range than [0, -1] some rounding error (?) seems to create that extra pixel offset for each event processed. This is on a 64-bit platform, in case this is important. Check out GetPointerEvents in xserver/dix/getevents.c. We take valuator coordinates, scale them to screen coords based on the axis information and then scale them back to device coords*. The screen coords are used to move the cursor and the scaling is done based on the axis ranges. Hence the different acceleration when you change the axis range to 0,-1 (in which case the screen coords are used as axis ranges). On top of it all, pointer acceleration kicks in as well. So the problem you're experiencing (i don't see it on similar hardware) can be: 1. in-driver scaling issues 2. server scaling issues 3. pointer accel issues 1. is easy to figure out by putting xf86Msg(X_ERROR, ...) before xf86PostMotionEvent and xf86PostButtonEvent in the driver and checking the valuators. If they change, the driver is to blame. 2 and 3 are a bit harder to find out, but narrowing it down to 1 or [2,3] would be good already. Cheers, Peter * the last step is buggy, we lose information here :( ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: pixman with and without SSE2 benchmarks?
I'd bet against that :-). Core 2 has magnificent SSE performance indeed, but that's true for MMX just as well. Well, Core2 (and AMD K10) got support for 128bit operations per clock, whereas previous processors only supported 64bit at once, and took 2 cycles for 128 bit operations. MMX is just 64-bit, so it should't matter much there. Clemens ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: current git head of Xserver segfaults on a keyhit
Peter, On Tue, Sep 23, 2008 at 04:01:19PM +0930, Peter Hutterer wrote: On Mon, Sep 22, 2008 at 08:08:37PM +0200, Lukas Hejtmanek wrote: the current git head of the Xserver segfaults on any keystroke. Trace is attached: Can I have a log please? any progress here? -- Lukáš Hejtmánek ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH] xf86-input-synaptics: fix creation of repeater fifo
On Sun, Sep 28, 2008 at 10:09:01AM +0100, Magnus Kessler wrote:
The creation of the repeater fifo in the synaptics driver looks dubious. The
file mode should be ORed with the S_IFIFO flag and the dev parameter should
be null. The mknod(3p) man page suggests using mkfifo instead.
Agreed.
[...]
repeater = xf86SetStrOption(local-options, Repeater, NULL);
if (repeater) {
/* create repeater fifo */
- status = mknod(repeater, 666, S_IFIFO);
- if ((status != 0) (status != EEXIST)) {
+ if (mkfifo(repeater, S_IWUSR|S_IRUSR|S_IWGRP|S_IRGRP|S_IWOTH|S_IROTH)) {
xf86Msg(X_ERROR, %s can't create repeater fifo\n, local-name);
} else {
/* open the repeater fifo */
Any special reason for dropping the EEXIST case?
Cheers,
Peter
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH] xf86-input-synaptics: fix creation of repeater fifo
On Sun, Sep 28, 2008 at 03:11:46PM +0100, Magnus Kessler wrote:
Testing status against EEXIST is wrong and we should check errno instead if
we want to allow the use of an existing file. However, since we pass a file
name that in principle could be any existing file (not just fifos) is there
any guarantee that we can later actually use the fifo?
Thanks. There is no guarantee that we can use it, but at the same time the
use-case where the pipe already exists is common.
In the simple case of a server restart, the first mkfifo command succeeds but
the second fails with EEXIST. So the pipe is still there and should be used.
Admittedly, it might be a good idea to clean up after ourselves and delete the
fifo if we have created it in the first place. What about the (compile-tested)
code below?
Cheers,
Peter
diff --git a/src/synaptics.c b/src/synaptics.c
index 18168e0..e5cb7f0 100644
--- a/src/synaptics.c
+++ b/src/synaptics.c
@@ -512,6 +512,9 @@ static void set_repeater_fifo(LocalDevicePtr local)
if (status (errno != EEXIST)) {
xf86Msg(X_ERROR, %s can't create repeater fifo\n, local-name);
} else {
+if (!status)
+priv-fifo_path = strdup(repeater); /* for unlinking later */
+
/* open the repeater fifo */
optList = xf86NewOption(Device, repeater);
if ((priv-fifofd = xf86OpenSerial(optList)) == -1) {
@@ -608,6 +611,7 @@ SynapticsPreInit(InputDriverPtr drv, IDevPtr dev, int flags)
DBG(9, XisbTrace(priv-comm.buffer, 1));
priv-fifofd = -1;
+priv-fifo_path = NULL;
set_repeater_fifo(local);
if (!QueryHardware(local)) {
@@ -655,6 +659,13 @@ static void SynapticsUnInit(InputDriverPtr drv,
InputInfoPtr local,
intflags)
{
+SynapticsPrivate *priv = (SynapticsPrivate *) (local-private);
+
+if (priv-fifo_path)
+{
+unlink(priv-fifo_path);
+xfree(priv-fifo_path);
+}
xfree(local-private);
local-private = NULL;
xf86DeleteInput(local, 0);
diff --git a/src/synapticsstr.h b/src/synapticsstr.h
index e5202d1..d93e279 100644
--- a/src/synapticsstr.h
+++ b/src/synapticsstr.h
@@ -96,6 +96,7 @@ typedef struct _SynapticsPrivateRec
struct CommData comm;
int fifofd;/* fd for fifo */
+char *fifo_path;/* path to fifo for unlinking */
SynapticsMoveHistRec move_hist[SYNAPTICS_MOVE_HISTORY]; /* movement
history */
int hist_index;/* Last added entry in move_hist[] */
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Having a two displays with driver intel (e.g. :0.0 and :0.1)
I have read lots of things on site site... no information about my concern is given infortunately. -- Romain Chossart On Sun, Sep 28, 2008 at 5:56 PM, Andrew Barr [EMAIL PROTECTED] wrote: Romain Chossart romainchossart at gmail.com writes: I would like to know if there was a possibility to use intel drivers (not i810) with *two displays* (e.g. :0.0 and :0.1) but only *one X server*. FWIW, the driver maintainers are reasonably good about keeping and updated and informative man page (part of the source distribution), and they have a Web site[0]. So maybe what you seek is covered there. [0] http://intellinuxgraphics.org/ -- Andrew ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
