Re: [ANNOUNCE] xf86-input-synaptics 0.99.1
Peter Hutterer wrote: > Synaptics 1.0 RC 1 > > Including features such as: > - better auto-calibration > - input property support > - new elantech touchpad support Is it just me or is VertEdgeScroll no longer on by default? I have to issue: synclient VertEdgeScroll=1 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: DeliverPropertyEvent() accessing unallocated memory
Matthieu Herrb wrote:
> Hi,
>
> using OpenBSD's memory allocator (which has an option to fill free()'d
> memory with a specific pattern) I found out that xserver 1.5.3 is
> dumping core on exit.
Same problem on git's master.
>
> This is caused by a bad pointer caused by accessing free'd memory in
> DeliverPropertyEvent, because when the RRProperties are destroyed, the
> associated windows have been free'd already.
>
So, no help on how to fix that? Should we just remove
RRDeleteAllOutputProperties() since it can't work?
> Here's a short debugging session that shows the problem (0xfd is the
> value used to fill free()'d regions:
>
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x1c1486f7 in DeliverPropertyEvent (pWin=0xdfdfdfdf, value=0xcfbc2400)
> at /usr/xenocara/xserver/randr/rrproperty.c:34
> 34 pHead = LookupIDByType(pWin->drawable.id, RREventType);
> (gdb) p **WindowTable
> $1 = {drawable = {type = 223 'ß', class = 223 'ß', depth = 223 'ß',
> bitsPerPixel = 223 'ß', id = 3755991007, x = -8225, y = -8225,
> width = 57311, height = 57311, pScreen = 0xdfdfdfdf,
> serialNumber = 3755991007}, devPrivates = 0xdfdfdfdf, parent =
> 0xdfdfdfdf,
> nextSib = 0xdfdfdfdf, prevSib = 0xdfdfdfdf, firstChild = 0xdfdfdfdf,
> lastChild = 0xdfdfdfdf, clipList = {extents = {x1 = -8225, y1 = -8225,
> x2 = -8225, y2 = -8225}, data = 0xdfdfdfdf}, borderClip = {extents = {
> x1 = -8225, y1 = -8225, x2 = -8225, y2 = -8225}, data = 0xdfdfdfdf},
> valdata = 0xdfdfdfdf, winSize = {extents = {x1 = -8225, y1 = -8225,
> x2 = -8225, y2 = -8225}, data = 0xdfdfdfdf}, borderSize = {extents = {
> x1 = -8225, y1 = -8225, x2 = -8225, y2 = -8225}, data = 0xdfdfdfdf},
> origin = {x = -8225, y = -8225}, borderWidth = 57311,
> deliverableEvents = 57311, eventMask = 3755991007, background = {
> pixmap = 0xdfdfdfdf, pixel = 3755991007}, border = {pixmap =
> 0xdfdfdfdf,
> pixel = 3755991007}, backStorage = 0xdfdfdfdf, optional = 0xdfdfdfdf,
> backgroundState = 3, borderIsPixel = 1, cursorIsNone = 1, backingStore
> = 1,
> saveUnder = 1, DIXsaveUnder = 1, bitGravity = 15, winGravity = 13,
> overrideRedirect = 1, visibility = 3, mapped = 1, realized = 1,
> viewable = 0, dontPropagate = 7, forcedBS = 1, redirectDraw = 3,
> forcedBG = 1}
> (gdb) bt
> #0 0x1c1486f7 in DeliverPropertyEvent (pWin=0xdfdfdfdf, value=0xcfbc2400)
> at /usr/xenocara/xserver/randr/rrproperty.c:34
> #1 0x1c025c5c in TraverseTree (pWin=0x879d7900,
> func=0x1c1486d0 , data=0xcfbc2400)
> at /usr/xenocara/xserver/dix/window.c:225
> #2 0x1c025d03 in WalkTree (pScreen=0x81310400,
> func=0x1c1486d0 , data=0xcfbc2400)
> at /usr/xenocara/xserver/dix/window.c:253
> #3 0x1c148858 in RRDeliverPropertyEvent (pScreen=0x81310400,
> event=0xcfbc2400)
> at /usr/xenocara/xserver/randr/rrproperty.c:62
> #4 0x1c1488d2 in RRDeleteAllOutputProperties (output=0x88fa2000)
> at /usr/xenocara/xserver/randr/rrproperty.c:80
> #5 0x1c147c9f in RROutputDestroyResource (value=0x88fa2000, pid=60)
> at /usr/xenocara/xserver/randr/rroutput.c:410
> #6 0x1c025078 in FreeClientResources (client=0x7d3f1400)
> at /usr/xenocara/xserver/dix/resource.c:809
> #7 0x1c02515e in FreeAllResources ()
> at /usr/xenocara/xserver/dix/resource.c:826
> #8 0x1c021acd in main (argc=1, argv=0xcfbc2578, envp=0xcfbc2580)
> at /usr/xenocara/xserver/dix/main.c:453
> (gdb)
>
>
> Ideas for fixing that are of course welcome.
>
--
Matthieu Herrb
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: conflicting memory types in system logs
Halim Issa wrote: > Hello, > > On X.Org X Server 1.5.3 with the Intel 2.5.1 driver on a Lenovo X200 laptop, > I > get quite a few error messages output in /var/log/messages where the kernel > complains about conflicting memory types. Is this just warnings, or something > to be taken seriously? If the latter, is it due to a config error on my part, > or a version mismatch or bug somewhere? > > System information included at bottom. > > Thanks in advance for any insight. > > X:3052 conflicting memory types d000-e000 write-combining<->uncached- > minus > reserve_memtype failed 0xd000-0xe000, track write-combining, req > write-combining > X:3052 conflicting memory types d000-e000 write-combining<->uncached- > minus > reserve_memtype failed 0xd000-0xe000, track write-combining, req > write-combining > X:3058 freeing invalid memtype d000-e000 > X:3052 conflicting memory types d000-e000 write-combining<->uncached- > minus > reserve_memtype failed 0xd000-0xe000, track write-combining, req > write-combining > X:3059 freeing invalid memtype d000-e000 > X:3052 conflicting memory types d000-e000 write-combining<->uncached- > minus > reserve_memtype failed 0xd000-0xe000, track write-combining, req > write-combining > X:3060 freeing invalid memtype d000-e000 > X:3052 conflicting memory types d000-e000 write-combining<->uncached- > minus > reserve_memtype failed 0xd000-0xe000, track write-combining, req > write-combining > X:3061 freeing invalid memtype d000-e000 > > Some system information: > > X.Org X Server 1.5.3 > Release Date: 5 November 2008 > X Protocol Version 11, Revision 0 > Build Operating System: Slackware 12.1 Slackware Linux Project > Current Operating System: Linux asterix 2.6.27.6 #4 SMP Thu Nov 20 11:06:31 > CET 2008 i686 > Build Date: 14 November 2008 10:28:10AM > > (II) Module intel: vendor="X.Org Foundation" > compiled for 1.5.3, module version = 2.5.1 > Module class: X.Org Video Driver > ABI class: X.Org Video Driver, version 4.1 > > (II) intel(0): Integrated Graphics Chipset: Intel(R) Mobile Intel® GM45 > Express Chipset > (--) intel(0): Chipset: "Mobile Intel® GM45 Express Chipset" > (--) intel(0): Linear framebuffer at 0xD000 > (--) intel(0): IO registers at addr 0xF200 > (WW) intel(0): libpciaccess reported 0 rom size, guessing 64kB > > libpciaccess version 0.10.5 I get the same. I'm on 1.5.3 but with the xf86-video-radeonhd driver. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xf86-video-amd: Changes to 'master'
Someone with write access on kemper, please update the project-name variable in /git/xorg/driver/xf86-video-geode.git/hooks/update to 'xf86-video-geode' to avoid confusion. Thanks. -- Matthieu Herrb ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[IDEA] shrink xrender featureset
Currently there exist several operations in xrender that are better off client side or through some other graphic api (imo). Think of trapezoid rasterisation, gradient rendering, etc. Doing this stuff client side avoids unforseen migration issues and doesn't create any false impressions with the api users. My suggestion would be to deprecate everything, except solid, composite, cursor stuff and glyphs. The idea is to stop doing seemingly arbitrary graphics operations that end up causing slowness most of the time (if not worked around "properly"). At this stage noone accelerates these operations, so there can be no complaints about that. xrender is here to stay, but there are limits to it, so let's accept this and move on (for other needs). How do others feel about this? Maarten. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [IDEA] shrink xrender featureset
Hi, > Currently there exist several operations in xrender that are better > off client side or through some other graphic api (imo). Think of > trapezoid rasterisation, gradient rendering, etc. > Doing this stuff > client side avoids unforseen migration issues and doesn't create any > false impressions with the api users. Well, in my opinion this is not a question where to do the stuff (client/server) - but rather how. Both, trapezoids and gradients cause migration because EXA currently has a quite strict view on accaleration. If something can be done on hw its done by hw, otherwise eerything else is migrated out. You still could to the same on the server you would do on the server-side. Just imagine you copy gradients or traps to temporary surface before you use them in a composition operation - it would be the same as client side, except you don't need to copy everything arround. Furthermore drivers often can fallback efficiently, like Intel drivers with GEM. If you omit gradients or trapezoids you would also have to transport a lot of stuff over wire - not really nice. > My suggestion would be to deprecate everything, except solid, > composite, cursor stuff and glyphs. The idea is to stop doing > seemingly arbitrary graphics operations that end up causing slowness > most of the time (if not worked around "properly"). At this stage > noone accelerates these operations, so there can be no complaints > about that. Well at least nvidia plans to accalerate gradients as well as trapezoids in theirproprietary drivers. Intel also has plans to optimize gradients with shaders. My opinion is that RENDER is quite fine, but there are some parts where drivers are lacking. Hopefully the situation will improve soon, at least for gradients. - Clemens ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Emulate Double Click Events
Hello I would like to emulate double click event. I use XTestFakeButtonEvent, the double clicks works only if i send 2 consecutive XTestFakeButtonEvent. Do i have to use a timer to check the period from one event to another in order to emulate double click, thank you dana ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Radeon X300, dual head
On Fri, Nov 21, 2008 at 5:50 PM, Hans J. Koch <[EMAIL PROTECTED]> wrote: > Hi, > I used to have a working system with a Radeon X300 (RV370) card and two > monitors 1680x1050 each. I used an ancient xorg version (something like > 6.8, can't recall) and had a MergedFB+Xinerama configuration. Worked well > for me. > > A few days ago I dist-upgraded my Debian sid which brought me version > 7.3 of xserver-xorg. Since that I'm trying to get my dual head setup > working again... > > I understand that MergedFB has been replaced by RandR 1.2 extensions. > Sounds like a good concept to me, but unfortunately it doesn't work here. > > X correctly detects my hardware, but no matter what I do, I always have > the same output on DVI-0 and VGA-0. I googled around and found a lot of > pages describing how to setup xorg.conf, and I think it's OK. > > Question: Is this supposed to work or a known problem? What do I have > to do to get a working dual head setup again? yes it should work. you may need to add a virtual line to your config to reserve enough framebuffer space for your config. This page gives a pretty good overview of how to configure things with xrandr: http://wiki.debian.org/XStrikeForce/HowToRandR12 One problem that comes up from time to time is that the xserver will clone the outputs (drive both monitors with the same display controller rather than with independent display controllers). The xrandr utility doesn't seem to be smart enough to grab a new crtc when you select multi-head, so you sometimes have to specify the crtc. run xrandr --verbose to see how the topology is configured. You can use this set of commands to specify a crtc: xrandr --output VGA-0 --off xrandr --output VGA-0 --crtc1 --mode 1680x1050 xrandr --output VGA-0 --right-of DVI-0 Alex ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Radeon X300, dual head [SOLVED]
On Sat, Nov 22, 2008 at 01:22:58PM -0500, Alex Deucher wrote: > On Fri, Nov 21, 2008 at 5:50 PM, Hans J. Koch <[EMAIL PROTECTED]> wrote: > > Hi, > > I used to have a working system with a Radeon X300 (RV370) card and two > > monitors 1680x1050 each. I used an ancient xorg version (something like > > 6.8, can't recall) and had a MergedFB+Xinerama configuration. Worked well > > for me. > > > > A few days ago I dist-upgraded my Debian sid which brought me version > > 7.3 of xserver-xorg. Since that I'm trying to get my dual head setup > > working again... > > > > I understand that MergedFB has been replaced by RandR 1.2 extensions. > > Sounds like a good concept to me, but unfortunately it doesn't work here. > > > > X correctly detects my hardware, but no matter what I do, I always have > > the same output on DVI-0 and VGA-0. I googled around and found a lot of > > pages describing how to setup xorg.conf, and I think it's OK. > > > > Question: Is this supposed to work or a known problem? What do I have > > to do to get a working dual head setup again? > > yes it should work. you may need to add a virtual line to your config > to reserve enough framebuffer space for your config. This page gives > a pretty good overview of how to configure things with xrandr: > http://wiki.debian.org/XStrikeForce/HowToRandR12 > > One problem that comes up from time to time is that the xserver will > clone the outputs (drive both monitors with the same display > controller rather than with independent display controllers). The > xrandr utility doesn't seem to be smart enough to grab a new crtc when > you select multi-head, so you sometimes have to specify the crtc. run > xrandr --verbose to see how the topology is configured. > > You can use this set of commands to specify a crtc: > xrandr --output VGA-0 --off > xrandr --output VGA-0 --crtc 1 --mode 1680x1050 > xrandr --output VGA-0 --right-of DVI-0 Great, that does the trick. You made my day. It was quite boring with one of my two monitors turned off ;-) Thanks a lot, Hans ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xf86-video-amd: Changes to 'master'
On Sun, Nov 23, 2008 at 1:10 AM, Matthieu Herrb <[EMAIL PROTECTED]> wrote: > Someone with write access on kemper, please update the project-name > variable in /git/xorg/driver/xf86-video-geode.git/hooks/update to > 'xf86-video-geode' to avoid confusion. > Done. Dave. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
X forcing WheelEmulation
Hullo, since today I've noticed that my external mouse has started behaving oddly. Namely the movement (and less often the HWheel) started to just not work from in random intervals. But on the other hand all (other) buttons and the VWheel work normally all the time. I noticed that for some reason X enables the WheelEmulation. So I changed my .fdi to look like this: --[start]-- evdev 1 0 3 4 5 6 7 8 2 false --[stop]-- Now this is what I get from Xorg.0.log: --[start]-- EE) Logitech USB Receiver: Read error: No such device (II) config/hal: removing device Logitech USB Receiver (II) Logitech USB Receiver: Close (II) UnloadModule: "evdev" (EE) Logitech USB Receiver: Read error: No such device (II) config/hal: removing device Logitech USB Receiver (II) Logitech USB Receiver: Close (II) UnloadModule: "evdev" (II) config/hal: Adding input device Logitech USB Receiver (**) Logitech USB Receiver: always reports core events (**) Logitech USB Receiver: Device: "/dev/input/event4" (**) Logitech USB Receiver: ButtonMapping '1 0 3 4 5 6 7 8 2' (II) Logitech USB Receiver: Found 16 mouse buttons (II) Logitech USB Receiver: Found x and y relative axes (II) Logitech USB Receiver: Configuring as mouse (**) Option "EmulateWheel" "false" (**) Logitech USB Receiver: YAxisMapping: buttons 4 and 5 (**) Logitech USB Receiver: EmulateWheelButton: 4, EmulateWheelInertia: 10, EmulateWheelTimeout: 200 (II) XINPUT: Adding extended input device "Logitech USB Receiver" (type: MOUSE) (WW) config/hal: device Logitech USB Receiver already added. Ignoring. --[stop]-- System: xorg-server 1.5.3 (with the keyboard patch) evdev 2.1 Cheers, Matija -- gsm: +386 41 849 552 e-mail: [EMAIL PROTECTED] www: http://matija.suklje.name aim: hookofsilver icq: 110183360 jabber/g-talk: [EMAIL PROTECTED] msn: [EMAIL PROTECTED] yahoo: matija_suklje GPG/PGP fingerprint: FB64 FFAF B8DA 5AB5 B18A 98B8 2B68 0B51 0549 D278 signature.asc Description: This is a digitally signed message part. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [ANNOUNCE] xf86-input-synaptics 0.99.1
On Sat, Nov 22, 2008 at 11:54:52AM +, Colin Guthrie wrote: > Peter Hutterer wrote: > > Synaptics 1.0 RC 1 > > > > Including features such as: > > - better auto-calibration > > - input property support > > - new elantech touchpad support > > Is it just me or is VertEdgeScroll no longer on by default? > > I have to issue: > synclient VertEdgeScroll=1 yes and no. Depending on whether your touchpad can detect multi-finger gestures, the driver enables either edge scrolling or two-finger scrolling. On your touchpad two-finger scrolling should be enabled. Now there's two other factors that may influence the behaviour as well: some touchpads report ranges beyond what they can report (e.g. 1500 if the max you can actually reach is 1200). In this case the edge settings are out and you need to manually adjust them to get edge scrolling working again. the other problem is a bug in the synaptics kernel driver. Currently, all touchpads announce multi-finger capabilities, even if they don't have them. see http://lkml.org/lkml/2008/11/19/376 for a patch. So if twofinger scrolling doesn't work for you, then you're (like me) affected by the kernel bug and need to manually override it in your xorg.conf/fdi. Or just patch the kernel and provide testing feedback :) Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Emulate Double Click Events
On Sat, Nov 22, 2008 at 08:08:35PM +0200, dana goren wrote: > I would like to emulate double click event. > I use XTestFakeButtonEvent, the double clicks works only if i send > 2 consecutive XTestFakeButtonEvent. > Do i have to use a timer to check the period from one event to another > in order to emulate double click, the X Protocol does not specify double clicks, it is enforced by the toolkit by checking the timestamps between two press/release events. In your case, you need to send two button events within the period the toolkit expects. Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X forcing WheelEmulation
On Sat, Nov 22, 2008 at 11:28:18PM +0100, Matija Šuklje wrote: > Hullo, > > since today I've noticed that my external mouse has started behaving oddly. > Namely the movement (and less often the HWheel) started to just not work from > in random intervals. But on the other hand all (other) buttons and the VWheel > work normally all the time. > > I noticed that for some reason X enables the WheelEmulation. So I changed > my .fdi to look like this: emulateWheel is false by default, so I really don't know why you'd need this. > Now this is what I get from Xorg.0.log: > --[start]-- > EE) Logitech USB Receiver: Read error: No such device > (II) config/hal: removing device Logitech USB Receiver > (II) Logitech USB Receiver: Close > (II) UnloadModule: "evdev" > (EE) Logitech USB Receiver: Read error: No such device > (II) config/hal: removing device Logitech USB Receiver > (II) Logitech USB Receiver: Close > (II) UnloadModule: "evdev" > (II) config/hal: Adding input device Logitech USB Receiver > (**) Logitech USB Receiver: always reports core events > (**) Logitech USB Receiver: Device: "/dev/input/event4" > (**) Logitech USB Receiver: ButtonMapping '1 0 3 4 5 6 7 8 2' > (II) Logitech USB Receiver: Found 16 mouse buttons > (II) Logitech USB Receiver: Found x and y relative axes > (II) Logitech USB Receiver: Configuring as mouse > (**) Option "EmulateWheel" "false" > (**) Logitech USB Receiver: YAxisMapping: buttons 4 and 5 > (**) Logitech USB Receiver: EmulateWheelButton: 4, EmulateWheelInertia: 10, > EmulateWheelTimeout: 200 > (II) XINPUT: Adding extended input device "Logitech USB Receiver" (type: > MOUSE) > (WW) config/hal: device Logitech USB Receiver already added. Ignoring. The last line is the key. Why is your device being added twice? Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
RE: Wrong links, files not where they're supposed to be
> > * The source directories for 7.4 in the various directories
> > /releases/X11R7.4/src/{app,driver,font,lib,proto,util} only contain
> archives
> > for the components which were updated for the new release. The other
> > components necessary to build X.Org are missing. Strangely enough they
> are
> > all there in the /releases/X11R7.4/src/everything/ directory.
> >
> Do you have examples (or, even better, a list of missing files)? I see
> some absolute symlinks in X11R7.4/src/app/ on annarchy, which would
> probably break on mirrors. What url are you looking at?
I'm looking at the primary sites - http://www.x.org/ and
http://xorg.freedesktop.org/. Unless a bunch of packages were cut between
7.3 and 7.4, it looks like there are a few missing from
/releases/X11R7.4/src/everything/ as well, such as
app:
bdftopcf
beforelight
editres
fonttosfnt
fslsfonts
fstobdf
ico
lbxproxy
listres
oclock
proxymngr
rgb
rstart
scripts
showfont
twm
viewres
xbiff
xcalc
xclipboard
xclock
xconsole
xdbedizzy
xditview
xdm
xedit
xeyes
xfd
xfindproxy
xfontsel
xfs
xfsinfo
xfwp
xgc
xinit
xkbprint
xload
xlogo
xlsfonts
xmag
xman
xmessage
xmh
xmore
xphelloworld
xplsprinters
xprehashprinterlist
xrx
xsetpointer
xsm
xstdcmap
xtrap
xvidtune
driver:
xf86-input-calcomp
xf86-input-citron
xf86-input-digitaledge
xf86-input-dmc
xf86-input-dynapro
xf86-input-elo2300
xf86-input-elographics
xf86-input-fpit
xf86-input-hyperpen
xf86-input-jamstudio
xf86-input-magellan
xf86-input-magictouch
xf86-input-microtouch
xf86-input-mutouch
xf86-input-palmax
xf86-input-penmount
xf86-input-spaceorb
xf86-input-summa
xf86-input-tek4957
xf86-input-ur98
xf86-video-cyrix
xf86-video-imstt
xf86-video-nsc
xf86-video-vga
xf86-video-via
lib:
libXTrap
libXevie
libXprintAppUtil
libXprintUtil
liblbxutil
liboldX
libxkbui
libXp
proto:
printproto
xf86rushproto
xproxymanagementprotocol
util:
gccmakedep
imake
lndir
xorg-cf-files
Hopefully that's all of them.
Thank you,
Robert
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X forcing WheelEmulation
Dne nedelja 23. novembra 2008 je Peter Hutterer napisal(a): > emulateWheel is false by default, so I really don't know why you'd need > this. I know. I added it only after this started happening. > > (II) XINPUT: Adding extended input device "Logitech USB Receiver" (type: > > MOUSE) > > (WW) config/hal: device Logitech USB Receiver already added. Ignoring. > > The last line is the key. Why is your device being added twice? No idea. I only have it once mentioned in my '/etc/hal/fdi/policy/*.fdi' files. And this started as of today (or at the earliest yesterday evening) and I don't remember messing about with input device settings in that time. Except with the 'keyboard.fdi', but that doesn't include any "Logitech" or "mouse" lines anyway. I'm completely lost as to why this happens. It also strikes me odd why is there a "KEYBOARD" entry concerning my mouse all of the sudden (see below). I just restarted the whole box without the mouse plugged in and only plugged it in when everything was up and running already. And this is what the end of the X log looks like: --[start]-- (II) config/hal: Adding input device Logitech USB Receiver (**) Logitech USB Receiver: always reports core events (**) Logitech USB Receiver: Device: "/dev/input/event5" (**) Logitech USB Receiver: ButtonMapping '1 0 3 4 5 6 7 8 2' (II) Logitech USB Receiver: Found 16 mouse buttons (II) Logitech USB Receiver: Found x and y relative axes (II) Logitech USB Receiver: Configuring as mouse (**) Option "EmulateWheel" "false" (**) Logitech USB Receiver: YAxisMapping: buttons 4 and 5 (**) Logitech USB Receiver: EmulateWheelButton: 4, EmulateWheelInertia: 10, EmulateWheelTimeout: 200 (II) XINPUT: Adding extended input device "Logitech USB Receiver" (type: MOUSE) (II) config/hal: Adding input device Logitech USB Receiver (**) Logitech USB Receiver: always reports core events (**) Logitech USB Receiver: Device: "/dev/input/event6" (II) Logitech USB Receiver: Found 1 mouse buttons (II) Logitech USB Receiver: Found keys (II) Logitech USB Receiver: Configuring as keyboard (**) Logitech USB Receiver: YAxisMapping: buttons 4 and 5 (**) Logitech USB Receiver: EmulateWheelButton: 4, EmulateWheelInertia: 10, EmulateWheelTimeout: 200 (II) XINPUT: Adding extended input device "Logitech USB Receiver" (type: KEYBOARD) (**) Option "xkb_rules" "evdev" (**) Logitech USB Receiver: xkb_rules: "evdev" (**) Option "xkb_model" "evdev" (**) Logitech USB Receiver: xkb_model: "evdev" (**) Option "xkb_layout" "us" (**) Logitech USB Receiver: xkb_layout: "us" --[stop]-- Cheers, Matija -- gsm: +386 41 849 552 e-mail: [EMAIL PROTECTED] www: http://matija.suklje.name aim: hookofsilver icq: 110183360 jabber/g-talk: [EMAIL PROTECTED] msn: [EMAIL PROTECTED] yahoo: matija_suklje GPG/PGP fingerprint: FB64 FFAF B8DA 5AB5 B18A 98B8 2B68 0B51 0549 D278 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 to get fake input events to a Xinput2 master device?
On Sat, 22 Nov 2008 16:57:17 +1000 Peter Hutterer <[EMAIL PROTECTED]> wrote: > On Sat, Nov 22, 2008 at 01:52:48AM +0100, Christian Beier wrote: > > (1) Master Devices created on the fly: > > XTestFakeDeviceButtonEvent, etc. It injects the event server-sided as if the > event was created by the input driver (although there isn't one for MDs), so > it'll generate the appropriate core/device events. I only tested that to some > extent, so please file a bug if it doesn't quite work right. > Having said that, injecting events into a MD directly is a bit troublesome due > to the design of the MD/SD device hierarchy. This is one more thing that needs > fixing before XI2 actually comes out. Sounds in a way more feasible to me than hacking around with uinput. And x11vnc is doing it via XTEST as well. Okay, i can only submit key/button presses and motion events, but I can't get any more over the wire with RFB anyway. Or what's the catch with using XTEST? > > > (2) Fake Slave Devices > IMHO long-term uinput gives you much more flexibility than doing anything with > xtest. I'd definitely go for that approach. Tried this few minutes ago and it was surprisingly easy. So i have to to take back my remarks on XTEST in a way. The only thing I don't like is that my app then needs root privs... Cheers, Christian -- what is, is; what is not is possible. pgpzSnBXviifY.pgp Description: PGP signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
xset dpms force off
I am running a multi-head setup. I'd like to be able to turn off each head individually. I'm using the evil binary nvidia drivers to set up 4 screens as DISPLAY 0.0, 0.1, 0.2, and 0.3 I'm not using Xinerama or Twinview. xset -display :0.0 dpms force off turns off all 4 displays, as does xset -display :0.1 dpms force off and so on. Any way to reach in and turn off a particular display? Anyone know if this is possible with nouveau? Thanks, --Yan ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Additional NULL (??) layout group with evdev+hal
Hello Peter, after upgrading to xserver 1.5.2 using the new evdev + hal I'm observing that I receive an additional layout group. The gnome keyboard indicator is showing this as "??" and using the libxklavier test program I get: [1227322878,150,xklavier.c:xkl_engine_constructor/] Actual backend: XKB [1227322878,200,xklavier_xkb.c:xkl_xkb_load_all_info/] found 3 groups [1227322878,200,xklavier_xkb.c:xkl_xkb_load_all_info/] Group 2 has name [Germany] [1227322878,200,xklavier_xkb.c:xkl_xkb_load_all_info/] Group 1 has name [Japan] [1227322878,200,xklavier_xkb.c:xkl_xkb_load_all_info/] Group 0 has name [-] The German and Japanese Layout-Group is in my setup, but the system added an additional Group 0 with name "-"?? I already read though your blog (http://who-t.blogspot.com/), but could not find anything explaining such a odd behaviour. I added a lot of description and logfiles to a bug report at this link: https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/283128 I'm not using Autologin (that was causing trouble in other case). There are a lot of devices coming up with evdev/hal, but all have "de,jp" assigned (lshal). What could causing such a problem? What can I do to avoid this problem? Thank you very much. Best regards, Thomas ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
RE: Emulate Double Click Events
What is the time period the toolkit expects for double click events. > Date: Sun, 23 Nov 2008 09:27:01 +1000 > From: [EMAIL PROTECTED] > To: [EMAIL PROTECTED] > Subject: Re: Emulate Double Click Events > CC: xorg@lists.freedesktop.org > > On Sat, Nov 22, 2008 at 08:08:35PM +0200, dana goren wrote: > > I would like to emulate double click event. > > I use XTestFakeButtonEvent, the double clicks works only if i send > > 2 consecutive XTestFakeButtonEvent. > > Do i have to use a timer to check the period from one event to another > > in order to emulate double click, > > the X Protocol does not specify double clicks, it is enforced by the toolkit > by checking the timestamps between two press/release events. > In your case, you need to send two button events within the period the toolkit > expects. > > Cheers, > Peter > ___ > xorg mailing list > xorg@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/xorg _ Color coding for safety: Windows Live Hotmail alerts you to suspicious email. http://windowslive.com/Explore/Hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_safety_112008 ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
RE: Emulate Double Click Events
On Sun, 2008-11-23 at 06:09 +, micki _ wrote: > What is the time period the toolkit expects for double click events. This thread partially answers your question: http://lists.freedesktop.org/archives/xorg/2008-March/033766.html Kind regards, Fernando Carrijo. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
