Re: [ANNOUNCE] xf86-video-intel 2.6.3
Eric Anholt pisze: This is an easy one: two bugfixes for regressions in the last release. One broke initialization with UXA and DRI1, and the other made pixmap allocation on i915 take insane amounts of memory. Hi Eric, unfortunately [1] is still present in that release. I will fill bug report, but in meanwhile I'm providing Xorg log [2]. -Jacek --- [1] http://lists.freedesktop.org/archives/xorg/2009-March/044162.html [2] http://pin.if.uz.zgora.pl/~difrost/download/Xorg.0.log ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xf86-input-synaptics 1.0.99.3
'Twas brillig, and Peter Hutterer at 04/03/09 06:58 did gyre and gimble: Another snapshot before the release since a number of fixes went into this one. Most notably, syndaemon updated to use device properties by default. And a fix that caused synclient with properties to fail on 64-bit machines. Peter Hutterer (12): synclient: print an error if we can't find the synaptics device. syndaemon: fix minor typo in --help output. syndaemon: remove enable/disable_touchpad(), use toggle_touchpad instead syndaemon: move shm code into shm_init(). syndaemon: if we wanted XRECORD, but it failed, exit. syndaemon: use device properties unless SHM is requested. syndaemon: disable XRecord by default. synclient: XCloseDisplay doesn't like NULL-pointers. syndaemon: needs XI_LIBS to link now. synclient: don't print driver's package version info. Don't auto-include xorg-server.h in config.h Bump to 1.0.99.3 On a related note here Peter, I'm getting hugely negative feedback on the default two-finger-scroll and non-tapbutton1 settings. That's not a problem here but essentially I'm going to have to tweak the defaults or suffer lynching in the streets! So I've a couple questions you can maybe answer for me. 1. Are you tweaking things in Fedora (can't see anything obvious when I peak!) 2. What would be the recommended way to tweak things? I can do one of two things: A. Patch the synaptics driver. or B. Configure things in the FDI file, and patch the Xserver to ignore synaptics in the same way it currently ignores keyboard and [vm]mouse. If the user does not want to use hal then they wire it up themselves - they should be canny enough to work out the configuration needed if they are configuring their config in this way. That said, I'm looking for the path of least maintenance too. I think B is the neater solution, but only if you see this ultimately going into the xserver. So, in short WDYT? Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mandriva Linux Contributor [http://www.mandriva.com/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Cairo with glitz backend
On Tue, 2009-03-03 at 17:24 -0800, Bipin George Mathew wrote: I was looking into way of accelerating Cairo using a glitz-backend and had a bunch of related questions: - What is the current status of glitz? Is anyone working on it? People contribute patches occasionally, just recently we received quite a few to address some bit rot and improve conformance. - From the paper here http://www.usenix.org/events/usenix04/tech/freenix/full_papers/nilsson/nilsson_html/index.html, it looks like glitz was experimental. What are the areas that needs to be worked on in-order to make it mainstream? For glitz to be considered supported we essentially need two things: 1. It should pass the test suite. 2. A responsive and long-term maintainer (for both the cairo backend the glitz library). - What are the other options of accelerating Cairo? Glitz was an experiment to implement the XRender protocol on top of OpenGL. This may not be the best approach to take. Instead the emphasis has shifted onto using the new (introduced into cairo after glitz was conceived) high level backend api to offload as much of the drawing operation as possible to the h/w. (Or at least entertain that possibility and investigate different solutions.) So currently aside from glitz, there are experiments to show that simply doing basic compositing using OpenGL can be much faster than XRender: http://cgit.freedesktop.org/~anholt/cairo/log/?h=gl and http://cgit.freedesktop.org/~ickle/cairo/log/?h=opengl A slightly more ambitious (though it does have quite a few fundamental flaws of its own, chiefly among those is that he hasn't asked anyone from the cairo community to review it...) http://github.com/akyrtzi/cairo-gral/tree/master And my favourite (slightly biased since I'm the author ;-) is an example of what you can achieve with direct rendering: http://cgit.freedesktop.org/~ickle/cairo/log/?h=drm which, I claim, is just about as fast as you can make cairo on an eee/i915. (I welcome any patches to make it, and cairo, even faster :-) -ickle ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Problem with xorg and intel g43
Hi all, I made more tests with regard to the problem of my monitor (asus vw198s) not being correctly recognized: I tried with many distros (many flavour of ubuntu, knoppix and puppy) and the result is still the same: it is not recognized. I also tried with a different pc, with another graphic card (ati radeon) and I got the same result. How can I decide wether the problem is of the model of the monitor or, instead, of _my own_ monitor? In the second case, I guess I am out of luck, but in the first? I must add that, anyway, there should be also some issue related to the driver: the hard freeze that I get every now and then when using it with the intel device does never occur with the ati card. Moreover, when using knoppix (the very same disk to boot on both pc) on the pc with the ati card knoppix starts correctly, even if at a wrong resolution, while on the pc with the intel card knoppix every time has the hard freeze I described. I have only two way to boot knoppix, on the pc with the intel card: 1) boot in runlevel 2, then modify xorg.conf with my own modeline (specifying also the device), then start X; this way I get a correct 1680x1050 screen. 2) provide at boot time the kernel module for X with the option xmodule=i810 This way knoppix boot correctly but with a wrong resolution. All this makes me think that, anyway, there should be also some issue related to the intel module, but I can't imagine what. Does anybody have some hint? Many thanks Fabio ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [ANNOUNCE] xf86-video-intel 2.6.3
On Wed, Mar 4, 2009 at 08:14:00 +0100, Tino Keitel wrote: up to 2.6.1, the branches for the stable versions were called xf86-video-intel-2.x-branch. Since 2.6.2, a branch origin/2.6 is used. is this intended? (If yes, I can understand it, as it is much less to type) Yes. http://lists.freedesktop.org/pipermail/xorg/2009-February/044004.html Cheers, Julien ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Cairo with glitz backend
[...] - What are the other options of accelerating Cairo? Simply the XRender backend. The acceleration you get depends on how much xserver can accelerate XRender. As Chris said, it may be slower than some other options, but it is stable and usable today. ~kammal ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Problem with xorg and intel g43
Dear Fabio, where is your first message you are referring to. Could you please post a link. Am Mittwoch, den 04.03.2009, 12:00 +0100 schrieb Fabio: […] Does anybody have some hint? I also had problems getting the ASUS VW222S to work. Take a look at [1] for the hints I got to solve this. I can not comment on the freezes. Thanks, Paul [1] https://bugs.freedesktop.org/show_bug.cgi?id=17629 signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xf86-input-synaptics 1.0.99.3
'Twas brillig, and Colin Guthrie at 04/03/09 14:40 did gyre and gimble: 'Twas brillig, and Peter Hutterer at 04/03/09 06:58 did gyre and gimble: Another snapshot before the release since a number of fixes went into this one. Most notably, syndaemon updated to use device properties by default. And a fix that caused synclient with properties to fail on 64-bit machines. Seems this is segv'ing for me :s Confirmed by another user too, (both of us are 64 bit). The device is currently configured in xorg.conf (not via hal yet as per my previous mail), but only has Option SHMConfig on set and nothing more. (II) Synaptics touchpad driver version 1.0.99.3 (--) SynapticsMouse1 auto-dev sets device to /dev/input/event2 (**) Option Device /dev/input/event2 (II) SynapticsMouse1: x-axis range 1472 - 5472 (II) SynapticsMouse1: y-axis range 1408 - 4448 (II) SynapticsMouse1: pressure range 0 - 255 (II) SynapticsMouse1: finger width range 0 - 0 (II) SynapticsMouse1: buttons: left right middle double triple (--) SynapticsMouse1 touchpad found (**) SynapticsMouse1: always reports core events Backtrace: 0: /etc/X11/X(xorg_backtrace+0x26) [0x4eca36] 1: /etc/X11/X(xf86SigHandler+0x3e) [0x480a3e] 2: /lib64/libc.so.6 [0x7fd0ae38dab0] 3: /lib64/libc.so.6(strlen+0x30) [0x7fd0ae3d7710] 4: /etc/X11/X(xf86ActivateDevice+0x6c) [0x4918bc] 5: /etc/X11/X [0x491a66] 6: /etc/X11/X(InitInput+0x40) [0x468790] 7: /etc/X11/X(main+0x37a) [0x42ecaa] 8: /lib64/libc.so.6(__libc_start_main+0xe6) [0x7fd0ae37a446] 9: /etc/X11/X [0x42e179] Fatal server error: Caught signal 11. Server aborting Forgot to say this is with xserver 1.6 Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mandriva Linux Contributor [http://www.mandriva.com/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[SOLVED]Eeepc901 KMS: LDVS detection problems
Hello, I just wanted to let you know that the problem was solved by upgrading the kernel to the newly released 2.6.29-RC7 version. The EEEPC 901 works now very good with KMS... Regards, Daniel ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Problem with xorg and intel g43
Dear Fabio, where is your first message you are referring to. Could you please post a link. It is a thread of two months ago; here is the link http://lists.freedesktop.org/archives/xorg/2009-January/042176.html Does anybody have some hint? I also had problems getting the ASUS VW222S to work. Take a look at [1] for the hints I got to solve this. I can not comment on the freezes. [1] https://bugs.freedesktop.org/show_bug.cgi?id=17629 Thank you very much for this link. I see that, quite likely, there is an issue with this family of monitors and the intel driver but it seems quite hard to find it and fix it. If you read the old thread, you will discover that I got a working modeline using powerstrip under windows. I didn't know about cvt -v -r 1680 1050 which I discovered reading your link: I tried it and it gives me a different modeline with respect to the one I found. Namely, mine is Modeline 1680x1050 147.600 1680 1784 1968 2256 1050 1051 1054 1087 -hsync +vsync whereas cvt gives Modeline 1680x1050R 119.00 1680 1728 1760 1840 1050 1053 1059 1080 +hsync -vsync I will give it a try: maybe this will fix the crash...! Thanks Fabio ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xf86-input-synaptics 1.0.99.3
'Twas brillig, and Colin Guthrie at 04/03/09 14:47 did gyre and gimble: 'Twas brillig, and Colin Guthrie at 04/03/09 14:40 did gyre and gimble: 'Twas brillig, and Peter Hutterer at 04/03/09 06:58 did gyre and gimble: Another snapshot before the release since a number of fixes went into this one. Most notably, syndaemon updated to use device properties by default. And a fix that caused synclient with properties to fail on 64-bit machines. Seems this is segv'ing for me :s Confirmed by another user too, (both of us are 64 bit). The device is currently configured in xorg.conf (not via hal yet as per my previous mail), but only has Option SHMConfig on set and nothing more. (II) Synaptics touchpad driver version 1.0.99.3 (--) SynapticsMouse1 auto-dev sets device to /dev/input/event2 (**) Option Device /dev/input/event2 (II) SynapticsMouse1: x-axis range 1472 - 5472 (II) SynapticsMouse1: y-axis range 1408 - 4448 (II) SynapticsMouse1: pressure range 0 - 255 (II) SynapticsMouse1: finger width range 0 - 0 (II) SynapticsMouse1: buttons: left right middle double triple (--) SynapticsMouse1 touchpad found (**) SynapticsMouse1: always reports core events Backtrace: 0: /etc/X11/X(xorg_backtrace+0x26) [0x4eca36] 1: /etc/X11/X(xf86SigHandler+0x3e) [0x480a3e] 2: /lib64/libc.so.6 [0x7fd0ae38dab0] 3: /lib64/libc.so.6(strlen+0x30) [0x7fd0ae3d7710] 4: /etc/X11/X(xf86ActivateDevice+0x6c) [0x4918bc] 5: /etc/X11/X [0x491a66] 6: /etc/X11/X(InitInput+0x40) [0x468790] 7: /etc/X11/X(main+0x37a) [0x42ecaa] 8: /lib64/libc.so.6(__libc_start_main+0xe6) [0x7fd0ae37a446] 9: /etc/X11/X [0x42e179] Fatal server error: Caught signal 11. Server aborting Forgot to say this is with xserver 1.6 Did some digging... turns out reverting this commit fixed it up: http://cgit.freedesktop.org/xorg/driver/xf86-input-synaptics/commit/?id=c719553dac875824b2d2a8f7714a89998ab4828d As I said I (and my other victim) are both 64 bit, so I suspect the funny things you mention are happening even with this commit :s Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mandriva Linux Contributor [http://www.mandriva.com/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[ANNOUNCE] applewmproto 1.2.0
Jeremy Huddleston (4): Use sized types to avoid issues on x86_64 Revert previous struct changes to the userland applewm.h Added XAppleWMSendPSN to let server know the psn of the WM Version bump to 1.2.0 Paulo Cesar Pereira de Andrade (1): Janitor: Correct make distcheck and dont distribute autogen.sh git tag: applewmproto-1.2.0 http://xorg.freedesktop.org/archive/individual/proto/applewmproto-1.2.0.tar.bz2 MD5: 44e18d01857f9dfeb8628e317e786f31 applewmproto-1.2.0.tar.bz2 SHA1: 50eb0076700f2fed6b5a63369da74a1be9d5afd0 applewmproto-1.2.0.tar.bz2 http://xorg.freedesktop.org/archive/individual/proto/applewmproto-1.2.0.tar.gz MD5: 538b76020bb84d7c3278227e98ea2c7e applewmproto-1.2.0.tar.gz SHA1: e5dcecb3a3a6404e5b28cf834aac3e481e3eb3fb applewmproto-1.2.0.tar.gz ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Problem with xorg and intel g43
Am Mittwoch, den 04.03.2009, 20:26 +0100 schrieb Fabio: where is your first message you are referring to. Could you please post a link. It is a thread of two months ago; here is the link http://lists.freedesktop.org/archives/xorg/2009-January/042176.html Does anybody have some hint? I also had problems getting the ASUS VW222S to work. Take a look at [1] for the hints I got to solve this. I can not comment on the freezes. [1] https://bugs.freedesktop.org/show_bug.cgi?id=17629 Thank you very much for this link. I see that, quite likely, there is an issue with this family of monitors and the intel driver but it seems quite hard to find it and fix it. If you read the old thread, you will discover that I got a working modeline using powerstrip under windows. I didn't know about cvt -v -r 1680 1050 which I discovered reading your link: I tried it and it gives me a different modeline with respect to the one I found. Namely, mine is Modeline 1680x1050 147.600 1680 1784 1968 2256 1050 1051 1054 1087 -hsync +vsync whereas cvt gives Modeline 1680x1050R 119.00 1680 1728 1760 1840 1050 1053 1059 1080 +hsync -vsync I will give it a try: maybe this will fix the crash...! I doubt that it will help with the crash, because the graphics card should not know if the monitor cannot display the image. But who knows. Anyway, if it does not work, you should definitely file a bug report. Only then my problem was dealt with by the intel engineer. And I do not know if such problems need to be send to a specific intel list to get help. Thanks, Paul signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [ANNOUNCE] xf86-video-intel 2.6.3
On Mon, Mar 02, 2009 at 12:20:47 -0800, Eric Anholt wrote: This is an easy one: two bugfixes for regressions in the last release. One broke initialization with UXA and DRI1, and the other made pixmap allocation on i915 take insane amounts of memory. Eric Anholt (3): Disable fb resizing for DRI1-only server so that DRI1 can initialize. Only allocate pixmaps aligned for tiling when requested by DRI2 GetBuffers. Bump version to 2.6.3. git tag: 2.6.3 Hi, there I've just tested KMS on my lenovo 3000 n100 laptop, and there's one issue: it sets up 16bpp for some reason on my LVDS and I have no possibility to change it, it looks weird :( Is it known issue? Should I file a bug on freedesktop bugzilla? Also is it planned to fix bugs #19873 and/or #19738 in near future? Regards Vasily 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: How does X Server assign Window ID?
On Wed, Mar 04, 2009 at 04:57:17PM -0500, Sheng Yu wrote: Hi all, I have been tracking for a bug that makes my program crashing when calling function glXMakeCurrent. My program runs with multi-displays, ':0.0', ':1.0', ':1.1', ':2.0', ':2.1'. When glXMakeCurrent() is called to switch rendering context from ':0.0' to either ':1.0', ':1.1' or ':2.0', ':2.1', the program runs fine. However, if the rendering context is switch from ':1.1' to ':2.0', the program crashes with with a segmentation fault. The interesting thing I found when debugging is the window ID and root window ID for each display: display:':0.0',screen: 0, root window id: 315, window id: 71303171 display:':1.0',screen: 0, root window id: 595, window id: 2097156 display:':1.1',screen: 1, root window id: 597, window id: 4194308 display:':2.0',screen: 0, root window id: 595, window id: 2097156 display:':2.1',screen: 1, root window id: 597, window id: 4194308 It seems that X Server 1 and 2 assign window ID with the same strategy, which is different from X Server 0. I am wondering whether it is causing the crashing, which indicates problems in X Server settings. I have been digging into the source of X Server and I cannot find how the window ID is assigned. Could someone tell me which file I should look into? Thanks a lot! CreateRootWindow() in dix/window.c, through a call to FakeClientID(). Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
libpciaccess patch for multiple videocards/int 10 problem
Hi all. There's a patch that's attached to bugzilla bug 18160 that fixes the problem specified in that bug; now that it prevents xorg from hanging the machine, other bugs have become visible, but the patch attached to comment 30 seems to solve the problem. How do we go about getting this applied to libpciaccess? https://bugs.freedesktop.org/show_bug.cgi?id=18160 :) - | Name: Tim Nelson | Because the Creator is,| | E-mail: wayl...@wayland.id.au| I am | - BEGIN GEEK CODE BLOCK Version 3.12 GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V- PE(+) Y+++ PGP-+++ R(+) !tv b++ DI D G+ e++ h! y- -END GEEK CODE BLOCK- ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xf86-input-synaptics 1.0.99.3
On Wed, Mar 04, 2009 at 09:16:21AM +, Colin Guthrie wrote: On a related note here Peter, I'm getting hugely negative feedback on the default two-finger-scroll and non-tapbutton1 settings. That's not a problem here but essentially I'm going to have to tweak the defaults or suffer lynching in the streets! Yeah, I've seen bugreports that complain about these defaults too. For tapping: This is a definitive break to 0.15, with the feature being disabled now by default on most touchpads. There's arguments to both sides, one being that tapping enabled causes erroneous clicks, especially for those with reduced dexteriority. The other argument is of course that it's a feature that makes the touchpad attractive. Members from both groups can be quite vocal, so either default is wrong in some way. I don't care strongly enough either way. Tap has been disabled in the driver since September now, so I want to stick with it. Subjectively bad but predictable defaults are better than defaults that change every month. For scrolling: Many devices seem to be going towards multi-touch and for this reason I think two-finger scrolling is the better default. That's pretty much the only reason. Based on anecdotal evidence, those who are complaining tend to be the ones that know how to configure it to their defaults anyway. 1. Are you tweaking things in Fedora (can't see anything obvious when I peak!) No, I don't. I did fix up gsynaptics and synclient though and I'm now telling users that they can tweak it at runtime. IMO this is the best solution. 2. What would be the recommended way to tweak things? I can do one of two things: A. Patch the synaptics driver. or B. Configure things in the FDI file, and patch the Xserver to ignore synaptics in the same way it currently ignores keyboard and [vm]mouse. If the user does not want to use hal then they wire it up themselves - they should be canny enough to work out the configuration needed if they are configuring their config in this way. That said, I'm looking for the path of least maintenance too. I think B is the neater solution, but only if you see this ultimately going into the xserver. So, in short WDYT? If synclient/gsynaptics are insufficient, I'd patch the driver. fdi files as configuration were always frowned upon and were mostly used because of a lack of alternatives. Patching the server to ignore synaptics xorg.conf devices will not only increase maintainance for you (maintaining patches in two different repos, different behaviour to other distros) but also create _a lot_ of complaints about the xorg.conf devices not working. synaptics is about the only device where xorg.conf sections have continued to work through the whole input system rework. Breaking this will create a flood of bugs. Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[ANNOUNCE] xf86-input-synaptics 1.0.99.4
1.0.99.3 crashes on 64 bit machines. This is caused by different struct sizes in the server and the driver, due to a missing #define. Fixed now, please test. Peter Hutterer (2): include xorg-server.h from all driver source files. Bump to 1.0.99.4 git tag: xf86-input-synaptics-1.0.99.4 http://xorg.freedesktop.org/archive/individual/driver/xf86-input-synaptics-1.0.99.4.tar.bz2 MD5: 5fd30e63296d7845274525571508fbc9 xf86-input-synaptics-1.0.99.4.tar.bz2 SHA1: 4b986af046ad97a6b8f91604e61a452612eb8347 xf86-input-synaptics-1.0.99.4.tar.bz2 http://xorg.freedesktop.org/archive/individual/driver/xf86-input-synaptics-1.0.99.4.tar.gz MD5: 7bdd1f312fb01952b24cd8a1e8ad2b76 xf86-input-synaptics-1.0.99.4.tar.gz SHA1: ef6f1815a241ac35bc465a743dc669670893f32f xf86-input-synaptics-1.0.99.4.tar.gz pgpUBIuV5AubJ.pgp Description: PGP signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xf86-input-synaptics 1.0.99.3
On Wed, Mar 04, 2009 at 09:27:34PM +, Colin Guthrie wrote: 'Twas brillig, and Colin Guthrie at 04/03/09 14:47 did gyre and gimble: 'Twas brillig, and Colin Guthrie at 04/03/09 14:40 did gyre and gimble: 'Twas brillig, and Peter Hutterer at 04/03/09 06:58 did gyre and gimble: Another snapshot before the release since a number of fixes went into this one. Most notably, syndaemon updated to use device properties by default. And a fix that caused synclient with properties to fail on 64-bit machines. Seems this is segv'ing for me :s Confirmed by another user too, (both of us are 64 bit). The device is currently configured in xorg.conf (not via hal yet as per my previous mail), but only has Option SHMConfig on set and nothing more. (II) Synaptics touchpad driver version 1.0.99.3 (--) SynapticsMouse1 auto-dev sets device to /dev/input/event2 (**) Option Device /dev/input/event2 (II) SynapticsMouse1: x-axis range 1472 - 5472 (II) SynapticsMouse1: y-axis range 1408 - 4448 (II) SynapticsMouse1: pressure range 0 - 255 (II) SynapticsMouse1: finger width range 0 - 0 (II) SynapticsMouse1: buttons: left right middle double triple (--) SynapticsMouse1 touchpad found (**) SynapticsMouse1: always reports core events Backtrace: 0: /etc/X11/X(xorg_backtrace+0x26) [0x4eca36] 1: /etc/X11/X(xf86SigHandler+0x3e) [0x480a3e] 2: /lib64/libc.so.6 [0x7fd0ae38dab0] 3: /lib64/libc.so.6(strlen+0x30) [0x7fd0ae3d7710] 4: /etc/X11/X(xf86ActivateDevice+0x6c) [0x4918bc] 5: /etc/X11/X [0x491a66] 6: /etc/X11/X(InitInput+0x40) [0x468790] 7: /etc/X11/X(main+0x37a) [0x42ecaa] 8: /lib64/libc.so.6(__libc_start_main+0xe6) [0x7fd0ae37a446] 9: /etc/X11/X [0x42e179] Fatal server error: Caught signal 11. Server aborting Forgot to say this is with xserver 1.6 Did some digging... turns out reverting this commit fixed it up: http://cgit.freedesktop.org/xorg/driver/xf86-input-synaptics/commit/?id=c719553dac875824b2d2a8f7714a89998ab4828d As I said I (and my other victim) are both 64 bit, so I suspect the funny things you mention are happening even with this commit :s Thanks, fixed now with 1.0.99.4. A missing #define resulted in the struct sizes being different in the driver and the server. Quite entertaining. Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[Question] Is xrandr 1.2.99.4 useful on Ubuntu 9.04 alpha5 ?
Dear all, I build Xrandr 1.22.99.4 successfully, but I can't run it. The error message is poly request too large or internal Xlib length error. I guess it's caused by mismatch of libXrandr, so I build libXrandr-1.2.99.4, but failed with error gcc: @MALLOC_ZERO_CFLAGS@: No such file or directory. Do Ubuntu 9.04 alpha 5 support xrandr 1.2.99.4 ? I want to study RandR 1.3, but I find that xrandr 1.2.99.3 doesn't match the Matthias' ppt at FOSDEM09. For example, it doesn't support the command xrandr --outpu VGA --current . Would you please give me some suggestion or tell me the other Linux distribution which supports randr 1.3 perfectly? Thanks! Best wishes, Gordon ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [Question] Is xrandr 1.2.99.4 useful on Ubuntu 9.04 alpha5 ?
On Thu, Mar 05, 2009 at 11:15:08AM +0800, gordony...@viatech.com.cn wrote: Dear all, I build Xrandr 1.22.99.4 successfully, but I can't run it. The error message is poly request too large or internal Xlib length error. Gordon, you've stumbled across https://bugzilla.novell.com/show_bug.cgi?id=481863 See also http://lists.x.org/archives/xorg-devel/2009-March/000415.html http://lists.x.org/archives/xorg-devel/2009-March/000416.html Stefan Public Key available -- Stefan Dirsch (Res. Dev.) SUSE LINUX Products GmbH Tel: 0911-740 53 0Maxfeldstraße 5 FAX: 0911-740 53 479 D-90409 Nürnberg http://www.suse.deGermany - SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) - ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
