[ANNOUNCE] xf86-input-evdev 2.2.4
Fixing a regression introduced with 2.2.3. The fix to Bug #21832 in 2.2.3 prevented Alps touchpads from working with the evdev driver. These touchpads announce both relative and absolute axes, events from the latter get ignored with the fix to 21832. The fix special-cases touchpad initialization to give absolute axes precedence over relative if a touchpad or touchscreen is found. For more info see Bug 23126. http://bugs.freedesktop.org/show_bug.cgi?id=23126 Michael Witten (1): evdev.c: Fix/improve discrimination of rel/abs axes Peter Hutterer (1): evdev 2.2.4 git tag: xf86-input-evdev-2.2.4 http://xorg.freedesktop.org/archive/individual/driver/xf86-input-evdev-2.2.4.tar.bz2 MD5: 6d0bd6cd3f50a42687c663d4764aeb44 xf86-input-evdev-2.2.4.tar.bz2 SHA1: 617f2f2e8649653caa8bb78aaa71f0ebe8168189 xf86-input-evdev-2.2.4.tar.bz2 http://xorg.freedesktop.org/archive/individual/driver/xf86-input-evdev-2.2.4.tar.gz MD5: 3347b343b50837f225130f3441909f52 xf86-input-evdev-2.2.4.tar.gz SHA1: 6b8f67eb4ca26dd42b3a91bec2444a68d3d6d157 xf86-input-evdev-2.2.4.tar.gz pgplK2ieE4Qdp.pgp Description: PGP signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[ANNOUNCE] inputproto 1.9.99.901
XI2 protocol specificiation RC 1.
A bunch of documentation updates since the last .15 release. I expect a few
more documentation updates for the final release but no changes in the
protocol itself.
Peter Hutterer (13):
XI2proto.txt: update list of XI2 event types.
XI2proto.txt: Add some XI1 vs. XI2 interoperability descriptions.
XI2proto.h: Remove special doxygen tags.
XI2proto.txt: padding bytes must be zero.
XIproto.txt: clarify that the ClientPointer is set, even if implicitly.
XI2proto.txt: grabbing a slave does not detach it anymore.
XI2proto.txt: passive grabs can take XIAll{Master}Devices.
XI2proto.txt: sourceid on DeviceChanged is the device.
XI2proto.txt: typo fixes and minor clarifications.
XI2proto.txt: don't put field names in quotes.
XI2proto.txt: document ClientPointer in more detail.
Revert "XI2proto.txt: grabbing a slave does not detach it anymore."
inputproto 1.9.99.901 (RC 1)
git tag: inputproto-1.9.99.901
http://xorg.freedesktop.org/archive/individual/proto/inputproto-1.9.99.901.tar.bz2
MD5: f7d213547a2cd422fd4b895ba3cc422c inputproto-1.9.99.901.tar.bz2
SHA1: b7b3d904f7e5e08fac119c1c0270f4698f1bef3a inputproto-1.9.99.901.tar.bz2
http://xorg.freedesktop.org/archive/individual/proto/inputproto-1.9.99.901.tar.gz
MD5: 96a6e305a370081bca7694bd1ace4745 inputproto-1.9.99.901.tar.gz
SHA1: 06792e8b1b7fdb5d1166b546cbba89db16b35e1f inputproto-1.9.99.901.tar.gz
pgppFKFdlVkaH.pgp
Description: PGP signature
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
[ANNOUNCE] xextproto 7.1.0
xextproto 7.1.0 is a much-needed cleanup of the xextproto repository. All Xlib headers have been removed and a consistent naming scheme for the remainging protocol headers has been applied. Note that as a result of this file removal and renaming, xextproto is only partially compatible to other, already released modules. An upgrade of xextproto from 7.0.x to 7.1.0 also requires upgrades of libXext, libXtst, the X server and possible others. Peter Hutterer (2): lbxproto: remove debug macro and definition of lbxDebug. xextproto 7.1.0 git tag: xextproto-7.1.0 http://xorg.freedesktop.org/archive/individual/proto/xextproto-7.1.0.tar.bz2 MD5: d54562771718a02508c6e0255409145d xextproto-7.1.0.tar.bz2 SHA1: 78c1fd39befbc3e8ef8396b3ce5fb40294ebfeef xextproto-7.1.0.tar.bz2 http://xorg.freedesktop.org/archive/individual/proto/xextproto-7.1.0.tar.gz MD5: e300d76d7dd0ba43761b9b8d49def659 xextproto-7.1.0.tar.gz SHA1: d43427317ddf4e6eb7ceb52f5f42c9df14609d4d xextproto-7.1.0.tar.gz pgpuR8KfjfaTO.pgp Description: PGP signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
can't start with xorg-video-fbdev/vt8623fb
Hello, I need to run an X server in a tiny x86 machine. I wanted to do so using fb but whatever I do ends up with: (EE) FBDEV(0): FBIOPUT_VSCREENINFO succeeded but modified mode linux26 2.6.27.29 (vt8623fb) xorg-server 1.5.3 xf86-video-fbdev 0.4.0 (and later 0.4.1) xorg.conf was generated using Xorg -configure and the Display subsections removed to reduce noise. dmesg, fbset -i, Xorg.0.log and xorg.conf.new are attached please, may you enlighten me? Thanks, Alejandro Mery dmesg.txt.gz Description: application/gzip fbset.txt.gz Description: application/gzip xorg.conf.new.gz Description: application/gzip Xorg.0.log.gz Description: application/gzip smime.p7s Description: S/MIME Cryptographic Signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: touchscreens in multiscreen setups
2009/8/3 Peter Korsgaard : > Now, with xrandr instead of Xinerama there is only one screen and the > above doesn't work (the coordinates gets scaled to the entire screen > instead of the individual outputs). > > What is the suggested solution for this? Add randr output tracking to > evtouch or should evdev handle this instead? > FWIW - I have a wacom tablet, I presently (ab)use the four wacom "calibration" properties to map input device' core pointer updating to particular screen subregions. I keep meaning to wrap a friendly systray applet around it to do it on the fly. I've never used evtouch, a similar trick might work there though: Basically, if a driver has a wacom-like facility, where rectilinear calibration uses TopX/TopY/BottomX/BottomY coords in device space and allows large positive and negative values for them, you can (ab)use them to map the tablet's zero-to-m/zero-to-n xy area in device space to any rectangular subarea of your screen in pixel space if you want. Make them correspond to subarea that aligns with the output you want it to align with, and you're done. The basic trick is to set the TopX/TopY to the top-left of the X11 screen ...in tablet-relative device coordinates! (picturing the tablet area laid atop the screen area), and similar for the BottomX/BottomY and the bottom-right of the X11 screen. (If you actually need some actual calibration too, well the maths gets trickier) But it could even be that input devices offering those four parameters is all that's necessary for an adequate solution for absolute input devices and xrandr multihead, so long as you don't mind roundtripping on randr reconfigurations (the systray thingy would need to watch for reconfigurations, introspect the new configuration, and recalculate the appropriate device calibration parameters). e.g. Here's what I use to statically align wacom input devices of a 1280x1024 screen / 7220x5780 device cintiq below a 1600x1200 screen: Option "TopX" "0" Option "TopY" "-6773" Option "BottomX" "9025" Option "BottomY" "5780" Note the huge negative value for TopY - that's so that the driver is "fooled" into thinking the tablet covers the whole X11 screen with a Y axis from -6773 to 5780, and since the X11 screen is a rectangle and I have a dead area to the right of the 1280x1024 screen, I also need to account for that with the BottomX value. 5780 * 1200 / 1024 = 6773 (ish) 7220 * 1600 / 1280 = 9025 This is actually a similar trick to the "lockstep multihead proportional panning" trick outlined in the proportional panning patch I sent a bit back (that I do mean to do a revised version of... just working at glacial pace...) ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
xf86XInputSetScreen() equivalent for randr
Hi, I'm working on getting evtouch to play nicely with multi screen systems using randr instead of Xinerama. It used to do xf86XInputSetScreen() to bind a touchscreen to a specific screen, but this doesn't really work that nicely with randr. I don't quite see something similar to bind (E.G. transform from output coordinates to screen coordinates) to an output, but I might be missing something? Pointers to where to look are very welcome. -- Bye, Peter Korsgaard ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Help. x1600, dual monitors, DVI twitching
On Wed, Aug 5, 2009 at 3:24 PM, Ron King wrote: > Hi, > I'm on Fedora 11, M56 x1600, X server 1.6.2-3, ATI driver 6.12.2-14. > Laptop with docking station and dual Samsung SyncMaster 940Be LCDs. > Docking station has one VGA and one DVI-D. All works fine in XP, Fedora > 8 (using Xrandr 1.2, I believe). > > LVDS and VGA work fine, alone or dual. DVI produces a vertical twitch, > always. Running the cursor up the screen shows missing horizontal > lines. Modes appear to be correct and match published monitor modes. > Changing modelines with xorg.conf and Xrandr do not seem to have any > effects. Adding modes in Xrandr and using them causes the monitor to > blank, then return and still report the same problem. Monitor reports > 31.7kHz and 30Hz regardless of changes. Is this mode hard coded for > DVI-D somewhere? It sounds like your monitor doesn't like dvi coherent mode. try: xrandr --output DVI-0 --set coherent_mode 0 xrandr --output DVI-0 --off xrandr --output DVI-0 --auto If that doesn't work, you might try the driver from xf86-video-ati git master. The display issues may be due to underflow to the display controller. Alex ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Help. x1600, dual monitors, DVI twitching
Hi, I'm on Fedora 11, M56 x1600, X server 1.6.2-3, ATI driver 6.12.2-14. Laptop with docking station and dual Samsung SyncMaster 940Be LCDs. Docking station has one VGA and one DVI-D. All works fine in XP, Fedora 8 (using Xrandr 1.2, I believe). LVDS and VGA work fine, alone or dual. DVI produces a vertical twitch, always. Running the cursor up the screen shows missing horizontal lines. Modes appear to be correct and match published monitor modes. Changing modelines with xorg.conf and Xrandr do not seem to have any effects. Adding modes in Xrandr and using them causes the monitor to blank, then return and still report the same problem. Monitor reports 31.7kHz and 30Hz regardless of changes. Is this mode hard coded for DVI-D somewhere? Please advise and thanks...Ron ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Fix focus follow mouse usability problem
Harald Braumann wrote: > On Wed, 05 Aug 2009 12:08:54 +0200 > Simon Thum wrote: >> There is a distinct advantage the server has, namely, it knows more >> detail. So it could do a better job than a client/wm. But still that's >> far from perfect, which I guess is why reading tea leaves has been >> left to the client. > > I agree completely, but the question is: does the client have all the > tea leaves to read from? Here's where my knowledge of the technical > details is not deep enough. From what I understand, the WM would have > to grab the mouse (probably bad) and then receive all motion events > (maybe a problem over slow links). I don't think so. KWM (which I'm using) has delayed focus, but I'm unaware how exactly it works. Just tested, it does: It is possible to cross windows without any focus or visibility change. Since X motion events include timestamps from nearby the driver, I don't think the practical difference the server could make would be worth it. The benefit from knowing whether additional events are queued is marginal. Mileage may vary with network conditions. Cheers, Simon ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Fix focus follow mouse usability problem
On Wed, 05 Aug 2009 12:08:54 +0200 Simon Thum wrote: > Harald Braumann wrote: > > If it's not possible yet, are there plans to implement such > > functionality in the X server? Like sending an event whenever the > > pointer stops? > Well, X is in pretty much the same situation here; it just knows when > the mouse moves, or when it did so last time (plus something else > happens). > > There is a distinct advantage the server has, namely, it knows more > detail. So it could do a better job than a client/wm. But still that's > far from perfect, which I guess is why reading tea leaves has been > left to the client. I agree completely, but the question is: does the client have all the tea leaves to read from? Here's where my knowledge of the technical details is not deep enough. From what I understand, the WM would have to grab the mouse (probably bad) and then receive all motion events (maybe a problem over slow links). > A possible alternative could be to synthesize inferred proximity from > the driver and make $WM use that. This however doesn't exactly solve > the problem, is hard to do (especially above the driver), so I guess > devs will hate it. Cheers, harry signature.asc Description: PGP signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Intel i915 / GEM throttling / 2.6.31-rc
On Mon, Aug 03, 2009 at 16:58:54 +0200, Michał Kazior wrote: > Hello, > > Since the inclusion of a GEM throttling commit [1] to the 2.6.31 > release candidate I started to have serious issues using 3D > acceleration. > > 3D Applications which are rather simple tend to render themselves in > bursts (i.e. shows a dozen of frames and then freezes for a split of a > second; repeat). I've filed a bug at kernel bug [2], but now I'm > starting to think it might be (also) xserver issue. > > Recently I noticed a detail which led me here. Stepmania [3] is one of > those suffering applications. The interesting part I noticed is that > it can render perfectly fine when the game window does not have > keyboard focus. If it regains the focus/input - it starts to render in > those bursts again. Quake3-demo and glxgears on the other hand render > in bursts regardless of the input/focus. It doesn't seem to be WM > related too. I also see such bursts (or rather stuttering movements) with glxgears and neverball, but not with google earth and tuxracer. Regards, Tino ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Fix focus follow mouse usability problem
Harald Braumann wrote: > If it's not possible yet, are there plans to implement such > functionality in the X server? Like sending an event whenever the > pointer stops? Well, X is in pretty much the same situation here; it just knows when the mouse moves, or when it did so last time (plus something else happens). There is a distinct advantage the server has, namely, it knows more detail. So it could do a better job than a client/wm. But still that's far from perfect, which I guess is why reading tea leaves has been left to the client. A possible alternative could be to synthesize inferred proximity from the driver and make $WM use that. This however doesn't exactly solve the problem, is hard to do (especially above the driver), so I guess devs will hate it. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Problem building xserver 1.5.1
On Tue, Aug 4, 2009 at 09:39:44 -0300, Diego A. Fons wrote: > In file included from linuxPci.c:271: > /usr/include/linux/pci.h:453: error: expected '=', ',', ';', 'asm' or > '__attribute__' before 'pci_power_t' Looks like breakage in your kernel headers. Not really something X can fix... Cheers, Julien ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Problem building xserver 1.5.1
Hi, On Tue, Aug 04, 2009 at 08:28:47PM +0200, Diego A. Fons wrote: > Yes you're right, I don't have any PCI bus, I didn't mention it because > I thought it was mandatory for X. > > I'm building X11R7.4, downloading the tarballs from [1]. I couldn't find > any option to disable PCI, how do I disable PCI? I'm building kDrive > servers and xorg server, this are the options I choose: > > configure --prefix=/usr --disable-aiglx --disable-glx-tls > --enable-registry --disable-composite --disable-xtrap --disable-record > --disable-screensaver --disable-xdmcp --disable-xdm-auth-1 --disable-glx > --disable-dri --disable-dri2 --disable-xinerama --disable-xace > --disable-xselinux --disable-xcsecurity --disable-appgroup > --enable-xcalibrate --enable-tslib --enable-xevie --disable-cup > --enable-evi --disable-multibuffer --disable-fontcache --disable-dbe > --disable-xf86bigfont --disable-dpms --enable-xorg --disable-dmx > --disable-xvfb --disable-xnest --disable-xquartz --disable-x11app > --disable-xwin --disable-xprint --disable-xgl --disable-xglx > --disable-xegl --enable-kdrive --disable-xephyr --disable-xsdl > --disable-xfake --enable-xfbdev --disable-freetype --disable-secure-rpc > --enable-xorgcfg –disable-kbd_mode > > > When I build only the kDrive (--disable-xorg) server the error is not > there, so, how can I build xorg server? I'm working on a patch to set PCI related code as optional on Xorg server. There's a preliminary version here (to be applied on git version): http://lists.x.org/archives/xorg-devel/2009-July/001398.html With the VGA arbitration coming to the game, this patch will get a nice clean up. So I have to wait to rebase this work while the arbiter kernel code doesn't go upstream (with luck we will see on 2.6.32). Cheers, Tiago ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: about Intel(R) Textured Video and Overlay Video
Hi, That're two ways to render decoded video to screen. You could check if your system support one/or both of them by issuing command: xvinfo and to explicitly specify one of them , you need also check the corresponding port number for textured video or the overlay video. The port number could also be get by command xvinfo. For mplayer, you could specify the port this way: mplayer -vo xv:port=port_number videofile Thanks --Shuang kedahanzi wrote: > dear everyone, > what is the difference betweenIntel(R)TexturedVideoandOverlayVideo? > how do i decide to use Intel(R)TexturedVideo way or OverlayVideo way? > much thanks! > 2009-08-05 > > kedahanzi ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
about Intel(R) Textured Video and Overlay Video
dear everyone, what is the difference between Intel(R) Textured Video and Overlay Video? how do i decide to use Intel(R) Textured Video way or Overlay Video way? much thanks! 2009-08-05 kedahanzi ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
what is xvideo port?
dear everyone, what is xvideo port? much thanks! 2009-08-05 kedahanzi ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
