[ANNOUNCE] xinput 1.5.1
Only one functional change - test-xi2 prints out the event type name as well. All other changes are man page fixes and packaging fixes. Gaetan Nadon (5): .gitignore: use common defaults with custom section # 24239 Makefile.am: ChangeLog not required: EXTRA_DIST or *CLEANFILES #24432 Deploy the new XORG_DEFAULT_OPTIONS #24242 INSTALL, NEWS, README or AUTHORS files are missing/incorrect #24206 Makefile.am: add ChangeLog and INSTALL on MAINTAINERCLEANFILES Jeremy Huddleston (1): This is not a GNU project, so declare it foreign. Julien Cristau (1): Add Peter and Red Hat's copyright notices and licenses to COPYING Peter Hutterer (4): man: remove reference to XListInputDevices man: document XI2 options test-xi2: print event type name as well. xinput 1.5.1 Simon Thum (1): Clarify role of set-ptr-feedback git tag: xinput-1.5.1 http://xorg.freedesktop.org/archive/individual/app/xinput-1.5.1.tar.bz2 MD5: 82400f0ba63217df9b00d825532cea7d xinput-1.5.1.tar.bz2 SHA1: f8f45486de7d44b3d7274dfd24f988035fe05910 xinput-1.5.1.tar.bz2 http://xorg.freedesktop.org/archive/individual/app/xinput-1.5.1.tar.gz MD5: 0463541dc9a38581577318f593b21d14 xinput-1.5.1.tar.gz SHA1: a1c888e869e8c50c9b79779376833d7e26fd4bf6 xinput-1.5.1.tar.gz pgpytW1m65kM6.pgp Description: PGP signature ___ xorg-announce mailing list xorg-announce@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg-announce
Re: Matrox G450 and Samsung 2333HD
Thanks for the info, Felix. I turned off the Clone option in the ServerLayout section and added a Modeline to the Monitor section: Modeline 1920x1080 138.500 1920 1960 1995 2083 1080 1082 1087 1109 +hsync -vsync The modeline seems to be what made the difference, though I left Clone off. It looks okay for what I do (mostly text-based stuff). I'm not sure I'm going to like dropping from 2560x1024 (2 monitors) to 1920x1080, though. That's a 25% loss of width... However, having a single monitor makes life a bit easier, too... I guess I'll have to see how it goes. Thanks! On Sat, Mar 13, 2010 at 06:56:33PM -0500, Felix Miata wrote: On 2010/03/13 14:14 (GMT-0500) Michael George composed: I'm having trouble getting my 2333HD monitor to work at 1920x1080 on my Matrox G450 (with just one monitor). I have played with the xorg.conf file, but the best I can do is get it to 1600x1200 (I don't know how it can do 1200 rows when 1080 is the max). The Xorg.log output tells me: (II) MGA(0): Not using mode 1920x1080 (no mode of this name) but it appears to be using: (**) MGA(0): Default mode 1600x1200: 162.0 MHz, 75.0 kHz, 60.0 Hz (II) MGA(0): Modeline 1600x1200x60.0 162.00 1600 1664 1856 2160 1200 1201 1204 1250 +hsync +vsync (75.0 kHz) I've googled for help for hours, but nothing I've found has gotten me that max resolution. A while ago I had to move a multiboot system with G400 (with latest BIOS I could find) for other reasons, so while out of place, I connected it to my Vizio HDTV. Using openSUSE 11.1, it does do 1920x1...@60hz. xorg.conf (created by SaX2; 3D not enabled) http://fm.no-ip.com/tmp/SUSE/111/xorg.conf.63-1920x1080-oS111-SaX2-mga xorg.conf (as modified by me to suit personal taste; 3D not enabled) http://fm.no-ip.com/tmp/SUSE/111/xorg.conf.64-1920x1080x16bpp-96dpi-oS111-mga hwinfo --gfxcard: http://fm.no-ip.com/tmp/SUSE/111/hwinfogfxcard-G400.txt Xorg.0.log (using 2nd xorg.conf above): http://fm.no-ip.com/tmp/SUSE/111/xorg.0.log-oS111-1080p-mga xdpyinfo output: http://fm.no-ip.com/tmp/SUSE/111/xdpyinfo-mga-1080p.txt HTH -- -M There are 10 kinds of people in this world: Those who can count in binary and those who cannot. ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
xrandr and vmware resize issue
There seem to be some bugs in the vmware video driver that causes resizing the display via xrandr to not change the physical dimensions of the display. The result is a high dpi and large font sizes. I've ignored this for years since gnome can just force the setting to 96dpi but that doesn't help with non-gtk apps. Today, though, I finally set out to narrow down but came up only with workarounds. By default, xorg will choose 800x600 as the only acceptable default resolution since it doesn't seem to like any of the default modes: (II) VMWARE(0): Not using default mode 640x350 (vrefresh out of range) (II) VMWARE(0): Not using default mode 320x175 (bad mode clock/interlace/doublescan) (II) VMWARE(0): Not using default mode 640x400 (vrefresh out of range) (II) VMWARE(0): Not using default mode 320x200 (bad mode clock/interlace/doublescan) (II) VMWARE(0): Not using default mode 720x400 (vrefresh out of range) (II) VMWARE(0): Not using default mode 360x200 (bad mode clock/interlace/doublescan) (II) VMWARE(0): Not using default mode 320x240 (bad mode clock/interlace/doublescan) (II) VMWARE(0): Not using default mode 640x480 (vrefresh out of range) (II) VMWARE(0): Not using default mode 320x240 (bad mode clock/interlace/doublescan) (II) VMWARE(0): Not using default mode 640x480 (vrefresh out of range) ... (--) VMWARE(0): Virtual size is 800x600 (pitch 800) (**) VMWARE(0): *Default mode 800x600: 40.0 MHz, 37.9 kHz, 60.3 Hz (II) VMWARE(0): Modeline 800x600x60.3 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (37.9 kHz) (**) VMWARE(0): Default mode 800x600: 36.0 MHz, 35.2 kHz, 56.2 Hz (II) VMWARE(0): Modeline 800x600x56.2 36.00 800 824 896 1024 600 601 603 625 +hsync +vsync (35.2 kHz) (**) VMWARE(0): Default mode 640x480: 25.2 MHz, 31.5 kHz, 59.9 Hz (II) VMWARE(0): Modeline 640x480x59.9 25.18 640 656 752 800 480 490 492 525 -hsync -vsync (31.5 kHz) (==) VMWARE(0): DPI set to (96, 96) I worked around the problem by doing the following: * Add a modeline to xorg.conf for desired resolution (e.g. 1280x1024) * Adjust the HorizSync to allow this mode This properly sets the dimensions for 96dpi at this resolution, but they remain fixed if it is changed: $ xrandr -s 1280x1024 $ xdpyinfo | grep dimensions dimensions:1280x1024 pixels (339x271 millimeters) $ xdpyinfo | grep dots per inch resolution:96x96 dots per inch $ xrandr -s 1600x1200 $ xdpyinfo | grep dimensions dimensions:1600x1200 pixels (339x271 millimeters) $ xdpyinfo | grep dots per inch resolution:120x112 dots per inch There is a bug open since 2008 describing this, but it has no updates: http://bugs.freedesktop.org/show_bug.cgi?id=16049 I also found a note from the developer indicating there is a bug in getting modelines: http://communities.vmware.com/thread/201534 I've found a number of other threads, but they're all dead ends or use the xorg.conf workaround for a fixed resolution. I'm rather surprised this issue isn't more noticed than it is, so I wonder if there is some other way to get this to work or if I'm missing something. Any thoughts? Thanks, Dan ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Please help with Xorg
Hi everybody, I ask help here because I don't know anything more to do.. In the last times with a lot of distros I'm having a problem with the resolutions... If I change to 1024x768 I have black edges on both sides of my desktop... I have a Intel Graphic 4 Chipset Controller in my laptop, but I tried vesa drivers intel driver from xorg.conf but nothing! This is especially from the linux kernel 2.6.29 but I think it a problem with the xorg drivers... I think... The only recent distro that doesn't give this problem is ubuntu 9.10, with all the others I can't do nothing... I searched a lot of information but nothing.. I hope you will give some news that I don't know.. In next hours I will post my xorg.conf file, now I can't.. Thank you. -- View this message in context: http://old.nabble.com/Please-help-with-Xorg-tp27899352p27899352.html Sent from the Free Desktop - xorg mailing list archive at Nabble.com. ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
xf86-input-wacom slow downs starting xorg
Hi all my system with Xorg-server-1.7.5 needs about 8-10sec to start in my application. if i use xf86-input-wacom-0.10.4 for an thinkpad x200t with touch buildin it needs about 4 sec more to start. is this normal or is it possible to optimize the starttime? greetings Stephan -- ### OpenELEC.tv ### The free and open Mediacenter Distribution 4 you http://www.openelec.tv ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xf86-input-wacom slow downs starting xorg
On Mon, Mar 15, 2010 at 05:14:40AM +0100, Stephan Raue wrote: my system with Xorg-server-1.7.5 needs about 8-10sec to start in my application. if i use xf86-input-wacom-0.10.4 for an thinkpad x200t with touch buildin it needs about 4 sec more to start. is this normal or is it possible to optimize the starttime? the wacom driver is relatively complex and the boot process definitely has room for optimization. some of this work has already been done. Have you compared 0.10.4 against the current git master? Things should have improved by a little bit already. There's a few areas where we are not particularly efficient. ATM the driver has hardcoded sleeps in it to wait for a reply from a serial tablet (I think yours is a serial one). During the init period we can't just allocate a timer and go with it, we actually need to wait until the tablet has responded to us. That can be done better than a simple usleep though... Cheers, Peter ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
