Re: Problem: After exiting X-intel, console command line wraps around

[Dan Nicholson]

On Nov 19, 2011 9:45 PM, al...@verizon.net wrote:

 Hello,

 System: (B)LFS, i686-pc-linux-gnu, kernel-3.1.0, Udev-173, Xorg-7.6
  xorg-server-1.11.2
  xf86-video-intel-2.17.0
  xf86-input-keyboard-1.6.0 (not used - for reference)
  xf86-input-mouse-1.7.1(not used - for reference)
  xf86-input-evdev-2.6.0
  xf86-video-vesa-2.3.0
  xterm-276
 Board: ASUS P5E-VM HDMI with Intel G35/ICH9R
 Monitor: Samsung SM2494, Wide (16:9), DVI input (HDMI-DVI cable)

 SEQUENCE OF STEPS LEADING TO THE PROBLEM

 1. Reboot to command line (as opposed to graphics)
 2. startx ~/xterm   # go to X using the intel driver
 3. exit # Exit X to command line
 4. PROBLEM:  command line wraps around now
   (i.e., doesn't go to next line if text reaches end, as would normally
happen)

 COMMENTS

 A. Unlike the (default) intel driver above, the vesa driver doesn't
exhibit problem (4)

 B. The wrap-around problem doesn't change back to normal unless/until
  B1.  At (4) one logouts and logs back in
  B2.  At (4) one types
TERM=linux  # Strange (see C below)

 C. echo $TERM - linux at _all_ times (in command/text mode)

 D. echo $TERM - xterm-color (in X)

 E. 'setterm -linewrap on|off' doesn't have any effect (like B above,
 i.e., doesn't restore system to normal)

What does $COLUMNS say afterwards? Does stty columns 80 fix it?

Dan
___
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Your subscription address: arch...@mail-archive.com

Re: udev action only for connecting VGA/HDMI cable but not for disconnecting

[Dan Nicholson]

On Fri, Aug 19, 2011 at 5:03 AM, Dirk Montgomery q...@gmx.de wrote:

 Hello all,

 I have an AMD Radeon HD 6310 with free radeonhd drivers running. Xorg
 version is 7.6, xserver is 1.10.3.

 I tried to define a udev rule to change my monitor settings autoamtically
 when I connect a VGA or an HDMI cable. Connecting works fine but
 disconnecting is not recognized.

 udevadm monitor shows:

 udevadm monitor

 monitor will print the received events for:
 UDEV - the event which udev sends out after rule processing
 KERNEL - the kernel uevent

 KERNEL[100.176249] change   /devices/pci:00/:00:01.0/drm/card0 (drm)
 UDEV  [100.869104] change   /devices/pci:00/:00:01.0/drm/card0 (drm)

 for connecting. For disconnecting nothing happens. Of course with this it is
 not possible to define a rule to change resolution etc. when cable is
 disconnected.

Since this source of this is entirely in the drm kernel module, the
xorg list may not be the best place to find out. What kernel are you
running? It might make sense to ask on one of the dri mailing lists if
no one responds here:

http://dri.freedesktop.org/wiki/MailingLists

--
Dan
___
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Your subscription address: arch...@mail-archive.com

Re: libX11 and libXext (at least) fail using prefix on make install

[Dan Nicholson]

On Mon, Jun 20, 2011 at 3:12 AM, Garry Iglesias
garry.igles...@gmail.com wrote:
 Hi,

 Sorry if this problem has already been mentioned, but I couldn't find
 any question nor bug about it...

 I'm building a libX11 and libXext as static libraries in a local tree as
 third party dependencies of a framework I'm working on. It's been
 working like a charm for 3 years, but I recently (yesterday) upgraded
 to the last versions of the libs. And I encounter a failure on install:
  make install doesn't use the prefix and try to write directly into
 /usr/share/ which is a problem:

 
 libX11 build log:

 [...]
 Making install in libX11
 make[2]: Entering directory
 `/shared-a/nshq/dev/ns2/third-party/Xlib/libX11-1.4.3/specs/libX11'
 make[3]: Entering directory
 `/shared-a/nshq/dev/ns2/third-party/Xlib/libX11-1.4.3/specs/libX11'
 make[3]: Nothing to be done for `install-exec-am'.
 test -z /home/giglesias/development/ns2/third-party/build/share/doc/libX11
 || /usr/bin/mkdir -p
 /home/giglesias/development/ns2/third-party/build/share/doc/libX11
  /usr/bin/ginstall -c -m 644 libX11.xml AppA.xml AppB.xml AppC.xml
 AppD.xml CH01.xml CH02.xml CH03.xml CH04.xml CH05.xml CH06.xml
 CH07.xml CH08.xml CH09.xml CH10.xml CH11.xml CH12.xml CH13.xml
 CH14.xml CH15.xml CH16.xml credits.xml glossary.xml
 '/home/giglesias/development/ns2/third-party/build/share/doc/libX11'
 test -z /usr/share/sgml/X11/dbs || /usr/bin/mkdir -p 
 /usr/share/sgml/X11/dbs
  /usr/bin/ginstall -c -m 644 libX11.html.db libX11.fo.db
 '/usr/share/sgml/X11/dbs'
 /usr/bin/ginstall: cannot remove
 `/usr/share/sgml/X11/dbs/libX11.html.db': Permission denied

I think this must be picking up your host's pkg-config file for
xorg-sgml-doctools that determine where to install the cross reference
databases for the documents. Do you see the following line during
configure?

checking for X.Org SGML entities = 1.7... /usr/share/sgml

The fix is either to install a new copy of xorg-sgml-doctools for your
prefix before libX11/libXext, or just disable the build of the spec
docs with --disable-specs. If you're just installing X as a
dependency, you may not care about the spec docs (they take a long
time to build, too). I think the next release of these modules will
have that fixed so the files follow --prefix, but I don't know when
that will be.

--
Dan
___
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Your subscription address: arch...@mail-archive.com

Re: evdev devices in xorg.conf

[Dan Nicholson]

On Mon, May 2, 2011 at 11:50 PM, Zoltan Szecsei zolt...@geograph.co.za wrote:
 On 2011-05-03 08:21, Peter Hutterer wrote:

 On Tue, May 03, 2011 at 07:47:24AM +0200, Zoltan Szecsei wrote:

 that just means that the device didn't get added for some reason. Nothing
 that should affect the working of the server (other than that you
 obviously
 can't use this device). If you ssh in before, you'll probably notice that
 this line is already in the log while you're logging in. from your last
 backtrace, it's the graphics driver that hangs.



 Hi Peter,
 Nope - I have had the machine on for a while this morning, and not logged in
 via the consoe.

 I've just dived in over ssh and extracted these files:

[12.888] (II) Using input driver 'evdev' for 'Mousetop'
[12.888] (II) Loading /usr/lib/xorg/modules/input/evdev_drv.so
[12.888] (**) Option CorePointer
[12.888] (**) Mousetop: always reports core events
[12.888] (EE) Mousetop: No device specified.
[12.888] (EE) PreInit returned 2 for Mousetop

As the log suggests, you're not specifying a device for Mousetop since
it's commented out:

Section InputDevice
Identifier Mousetop
#Driver mouse
#OptionPhys   usb-:00:1d.7-4.3/input1
Driver evdev
OptionPhys   pci-:00:1d.1-usb-0:2:1.1-event-mouse
#   Option Device /dev/input/event3
Option Protocol auto
Option ZAxisMapping 4 5
Option Emulate3Buttons true
EndSection

On the one hand, you can fix it, but you'll probably get duplicate
devices since the server is adding devices automatically. Here's your
keyboard getting added:

[12.977] (II) config/udev: Adding input device Logitech USB
Receiver (/dev/input/event2)
[12.977] (**) Logitech USB Receiver: Applying InputClass evdev
keyboard catchall
[12.977] (II) Using input driver 'evdev' for 'Logitech USB Receiver'
[12.977] (II) Loading /usr/lib/xorg/modules/input/evdev_drv.so

Unless you have a good reason to keep the static InputDevice sections,
you may just want to comment them out and let the server add the
devices as it finds them. If you find that you prefer to keep the
static device configuration for one reason or another, I suggest
adding Option AutoAddDevices false to your server flags.

However, Peter's right that your freeze was caused by the nvidia
driver. Fixing these PreInit errors won't change that situation.

--
Dan
___
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Your subscription address: arch...@mail-archive.com

Re: xorg-macros does not install the .pc file in the standard location

[Dan Nicholson]

On Sun, Apr 17, 2011 at 11:36 PM, Vincent Torri vto...@univ-evry.fr wrote:

 hey

 in Makefile.am,

 pkgconfigdir = $(datadir)/pkgconfig

 should be replaced by

 pkgconfigdir = $(libdir)/pkgconfig

Since the macros are arch-independent $datadir/pkgconfig is the
correct location. See the default setting for PKG_CONFIG_PATH in
pkg-config(1).

--
Dan
___
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Your subscription address: arch...@mail-archive.com

Re: A request for Matrox driver procedure

[Dan Nicholson]

On Mon, Mar 21, 2011 at 5:31 AM, Suresh.M sures...@procreateisi.com wrote:
 Dear friends of the Linux Community!



 My name is Suresh. M and I am sales person.



 I need a help from all of you that is one of our customer is having
 supermicro server  and OS is Redhat 3 update 8.



 He wanted high definition resolution. However, There are no VGA drivers
 available for Redhat 3 Update 8. The best bet would be to use xorg driver
 and compile it on



 RHEL3 update 8. There is package called mga which works for matrox graphics
 driver.



 You must know however, that I'm not an engineer. So, customer need procedure
 to install this driver.



 Please help giving this procedure.

RHEL3 is an old distribution, and I don't believe the people here will
be able to help too much since the current drivers probably won't work
there. However, I would suggest that your customer contact Red Hat for
support. They would know the best way to supply working graphics on
their platform.

--
Dan
___
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Your subscription address: arch...@mail-archive.com

Re: How to enable software rendering via X server

[Dan Nicholson]

On Mon, Feb 14, 2011 at 11:15 PM, Neeraj N T neera...@tataelxsi.co.in wrote:
 I set LIBGL_ALWAYS_SOFTWARE=1.But the output I got was the same:

 direct rendering: No
 OpenGL renderer string: Mesa DRI Intel(R) IGDNG_M GEM 20091221 2009Q4

This means you also have LIBGL_ALWAYS_INDIRECT set, which means the
server is creating the GLX context. I don't think you can easily
control which dri driver the server opens, but I might be wrong. So,
if you have LIBGL_ALWAYS_SOFTWARE set and LIBGL_ALWAYS_INDIRECT unset,
then you should get direct rendering with the swrast.

To review,

LIBGL_ALWAYS_INDIRECT: use the X server's GLX context. This used to
mean you'd also get software rendering, but with AIGLX you'll probably
get the hardware DRI driver.

LIBGL_ALWAYS_SOFTWARE: tell libGL to use the software renderer. This
only works with direct rendering because otherwise you're getting the
DRI driver that the X server opened, and it's not controlled by this
variable.

--
Dan
___
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Your subscription address: arch...@mail-archive.com

Re: Brain-Wracking Configurations

[Dan Nicholson]

On Fri, Feb 4, 2011 at 2:29 PM, Justin Briggs red.kenn...@gmail.com wrote:
 I'm trying to configure XOrg 7.4 to use the dvorak keyboard layout with the
 macbook79 model, and am having absolutely no success. I've tried all kinds
 of options in 10-evdev.conf as well as xorg.conf and have no idea how the
 newer configuration system works. I had no problems getting all set up 2 or
 3 years ago.

Can you send your Xorg log? Can you attach your xorg.conf? This is the
expected way I'd do it:

Section InputClass
Identifier Keyboard Settings
MatchIsKeyboard yes
Option XkbLayout dvorak
Option XkbModel macbook79
EndSection

--
Dan
___
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Your subscription address: arch...@mail-archive.com

Re: Custom modeline in 10-monitor.conf?

[Dan Nicholson]

On Sat, Dec 4, 2010 at 12:57 PM, Felix Miata mrma...@earthlink.net wrote:
 On 2010/12/04 12:23 (GMT-0800) Alan Coopersmith composed:

 Robert wrote:

  I upgraded xorg-server and I noticed it didn't read my settings. I
  figured that the new xorg probably must have deprecated the xorg.conf
  file, and that I would have to configure it in the new way of using
  /etc/X11/xorg.conf.d instead.

 /etc/X11/xorg.conf is not deprecated, and is still read by the upstream
 code.
 Some input device entries there are ignored since the advent of input
 hotplug,
 but that's been true since Xorg 1.4 or so.

 /etc/X11/xorg.conf.d extends /etc/X11/xorg.conf, but does not replace it.
 /etc/X11/xorg.conf.d is intended to replace .fdi files for input device
 configuration that were used by HAL for platforms which have moved off
 HAL.

  And sure enough, the arch linux wiki said
  that 10-monitor.conf is the new config file for monitor settings.

 That's a file created by your distro and a choice they've made to put
 monitor settings there.

 (Sorry, I don't know why your driver isn't honoring your modeline, but
  it shouldn't be because of the file you put it in.   I would bet it has
  a lot more to do with the Intel driver doing modesetting in the kernel
  instead of Xorg since the advent of KMS.)

 In testing *buntu*, Factory, Cooker  Rawhide I've been seeing more than
 just modelines being ignored in xorg.conf but not in xorg.conf.d/, and as
 yet have not found a pattern to help find out what is causing it. Could this
 really be some KMS kernel fault? see e.g.
 http://lists.x.org/archives/xorg-driver-ati/2010-November/018097.html

 What are those wanting custom user config and exporting XORGCONFIG to do it
 supposed to do when their alternate xorg.conf files are not obeyed like they
 used to be?

I think I know what the reason might be (since I wrote the xorg.conf.d code).

In order to maintain the input option semantics where each subsequent
InputClass takes precedence over the previous, xorg.conf is the last
.conf file read. However, this might conflict with the output option
semantics where the first match found is used. So, my guess is that
the modeline is being found in xorg.conf.d and doesn't continue to
look for options. I haven't looked at it, but it wouldn't be hard to
make the server keep looking for output sections to use instead of
stopping at the first.

My intention wasn't to allow multiple Device/Monitor/Screen sections
in xorg.conf.d installed by the distro. It seems like 10-monitor.conf
is being generated on the fly and these aren't generic settings.
Device/Monitor/Screen aren't really built to have multiple sections
like InputClass.

--
Dan
___
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Your subscription address: arch...@mail-archive.com

Re: [PATCH 1/5] build: use AC_CONFIG_MACRO_DIR as per libtoolize warning

[Dan Nicholson]

On Sun, Nov 28, 2010 at 1:39 PM, Gaetan Nadon mems...@videotron.ca wrote:
 On Sun, 2010-11-28 at 21:26 +0100, Jan Engelhardt wrote:

 On Sunday 2010-11-28 19:45, Gaetan Nadon wrote:

On Sun, 2010-11-28 at 15:46 +0100, Jan Engelhardt wrote:
  +ACLOCAL_AMFLAGS = -I m4

This will fail if m4 does not exist at clone time.
It won't because there is a .gotognore file in there.
However, it will be suggested later to use the same
toplevel .gitignore file that is used in all other 240 xorg modules.

 Then perhaps you need to update the master xorg .gitignore, because the
 suggestion to use ACLOACL_AMFLAGS will appear on any project with a
 libtool library.

 The suggestion to use ACLOCAL_AMFLAGS come from the Autoconf tools.
 I looked at the warnings and the output of autoupdate and autoscan and there
 are plenty of warnings that do not apply.

Pretty sure it's coming from libtoolize :)

libtoolize: Consider adding AC_CONFIG_MACRO_DIR([m4]) to configure.ac and
libtoolize: rerunning libtoolize, to keep the correct libtool macros in-tree.
libtoolize: Consider adding -I m4 to ACLOCAL_AMFLAGS in Makefile.am.

It's suggesting that you add AC_CONFIG_MACRO_DIR([m4]) so that it will
helpfully install it's m4 files there and attempt to make them
persistent. Jeremy Huddleston asked not to do this a while back
because it's then harder to replace the included libtool with the
patched version on OSX. Not sure if this is still a problem, but there
are definitely pros and cons to distributing the libtool macros in the
tree.

--
Dan
___
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Your subscription address: arch...@mail-archive.com

Re: latest git xserver without hal causes Hotplugging to be a bit tricky

[Dan Nicholson]

On Fri, Nov 26, 2010 at 8:24 PM, Justin Mattock justinmatt...@gmail.com wrote:
 hello,
 Not sure how to really handle this here(maybe I missed something), but
 under xorg.conf
 I see:
        /usr/lib/X11/fonts/100dpi/,
        /usr/lib/X11/fonts/75dpi/
 [   280.713] (**) ModulePath set to /usr/lib/xorg/modules
 [   280.713] (WW) Hotplugging is on, devices using drivers 'kbd',
 'mouse' or 'vmmouse' will be disabled.
 [   280.713] (WW) Disabling Mouse0
 [   280.713] (WW) Disabling Keyboard0
 [   280.713] (II) Loader magic: 0x7c9900
 [   280.713] (II) Module ABI versions:
 [   280.713]    X.Org ANSI C Emulation: 0.4

 startx works but I've no mouse or keyboard..
 (HAL is not installed)

It's using udev for hotplugging now unless you explicitly told it not
to during the build.

 if I

 Section ServerFlags
        Option AutoAddDevices False
 EndSection

 startx gets me a blank screen.

 is there a new option that I need to add to xorg.conf in order to startx
 and have radeon work right as well as the mouse and keyboard?
 or is this dependant on hal and/or device manager?
 (machine is a macbook pro)

Either remove Mouse0/Keyboard0 from your xorg.conf, add the above
ServerFlags to disable hotplugging, or rebuild with
--disable-config-udev to remove hotplugging entirely.

--
Dan
___
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Your subscription address: arch...@mail-archive.com

Re: [ANNOUNCE] xcalc 1.0.4

[Dan Nicholson]

On Fri, Nov 26, 2010 at 1:42 PM, Alan Coopersmith
alan.coopersm...@oracle.com wrote:
 Somchai Smythe wrote:
 I compared it to the install-sh in xcalc-1.0.3 and it seems random
 lines were deleted from the case statement.
 -    -g) chgrpcmd=$chgrpprog $2

 *sigh*   I see what happened now - the lines deleted are very much not
 random - they're the lines with $ in, due to my use of perl to remove
 CVS tags from * in that directory, not noticing I had a copy of install-sh
 in there (I usually build in separate directories so my git repos don't
 normally have those in).

 I'll go post new tarballs with a clean install-sh.   Sorry about that.
 (Strangely, make distcheck worked with the broken install-sh.)

Probably because distcheck doesn't exercise install-strip as far as I
can tell. It uses the normal install targets, which use
/usr/bin/install on most hosts.

--
Dan
___
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Your subscription address: arch...@mail-archive.com

Re: libX11 build error

[Dan Nicholson]

2010/11/22 Deniz Fer deniz@yaltes.com:
 Hello,



 I have a computer with CentOS 5.5 installed. My current Xorg version is
 attached and I want to upgrade to Release 7.5 (MPX being the main reason for
 the upgrade).



 I have followed every instruction in the wiki. I used manuel build with
 Peter’s instructions in FAQ, I have failed. I used jhbuild (after upgrading
 python and dbus), I have failed. Every time I have failed I get the same
 error which is “am_ET.UTF-8/XLC_LOCALE: command not found”. It’s a module in
 libX11, nls. I also tried to use –disable-xlocale with no success. After
 some research it appears that after configure, Makefile has an error in it
 self and it tries to use a command that is not present in my system.



 Probably I’m missing some other upgrade but couldn’t find what it might be.
 If anyone encountered this problem or something similar please help. Thank
 you for your time.

Could you cd into the libX11 directory, run make V=1 and then paste
the output here? We need to see the build error to know what went
wrong.

--
Dan
___
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Your subscription address: arch...@mail-archive.com

Re: Evdev keyboard sends keycodes but no keysyms

[Dan Nicholson]

On Wed, Nov 17, 2010 at 3:26 PM, Simon Thum simon.t...@gmx.de wrote:
 On 11/17/10 00:01, Peter Hutterer wrote:
 On Wed, Nov 17, 2010 at 01:33:34AM +0100, Simon Thum wrote:
 Hi all,

 no dice so far. I get some additional lines:

 [ 16085.444] (II) config/udev: Adding input device AT Translated Set 2
 keyboard (/dev/input/event4)
 [ 16085.444] (**) AT Translated Set 2 keyboard: Applying InputClass
 evdev keyboard catchall
 [ 16085.444] (**) AT Translated Set 2 keyboard: Applying InputClass
 keyboard-de
 [ 16085.444] (II) Loading /usr/lib64/xorg/modules/input/evdev_drv.so
 [ 16085.444] (**) AT Translated Set 2 keyboard: always reports core events
 [ 16085.444] (**) AT Translated Set 2 keyboard: Device: /dev/input/event4
 [ 16085.448] (--) AT Translated Set 2 keyboard: Found keys
 [ 16085.448] (II) AT Translated Set 2 keyboard: Configuring as keyboard
 [ 16085.448] (**) Option config_info
 udev:/sys/devices/platform/i8042/serio0/input/input4/event4
 [ 16085.448] (II) XINPUT: Adding extended input device AT Translated
 Set 2 keyboard (type: KEYBOARD)
 [ 16085.448] (**) Option xkb_rules evdev
 [ 16085.448] (**) Option xkb_model evdev
 [ 16085.448] (**) Option xkb_layout us
 [ 16085.448] (**) Option xkb_options terminate:ctrl_alt_bksp
 [ 16085.448] (II) XKB: Reusing cached keymap
 [ 16085.448] (II) config/udev: Adding input device SynPS/2 Synaptics
 TouchPad (/dev/input/event7)

 I even added the option xkb_layout, recompiled the whole stuff and so on.

 I'm using startx -- -logverbose, is that OK?

 try -logverbose 12 or something, otherwise you'll just increase by one.
 also, try to remove the cached keymaps, I wonder if something goes wrong
 there.
 That seems strange - I got an empty /var/cache/xkb (except for a
 README.compiled, might be installed by gentoo). Yet still, I'm getting
 that messag three timese: XKB: Reusing cached keymap.

 From my reading of the code that means it's initializing 4 keyboards?

It's reusing the in-memory cached keymap. Since it doesn't think
you've changed the Xkb options
(evdev/evdev/us//terminate:ctrl_alt_bksp), it's using the same keymap
it got from xkbcomp on the previous run. And yes, you have 4 keyboards
(3 by my count) in the sense that the kernel is presenting that many
devices with keys.

The real question is why Applying InputClass keyboard-de doesn't
change the layout to de even though it's the last class merged in. I
thought this log would give more info about how the settings are being
merged together, but I guess that part never really got done.

Looks like Peter confirmed it's a bug.

--
Dan
___
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Your subscription address: arch...@mail-archive.com

Re: Evdev keyboard sends keycodes but no keysyms

[Dan Nicholson]

On Tue, Nov 16, 2010 at 4:33 PM, Simon Thum simon.t...@gmx.de wrote:
 Hi all,

 no dice so far. I get some additional lines:

 [ 16085.444] (II) config/udev: Adding input device AT Translated Set 2
 keyboard (/dev/input/event4)
 [ 16085.444] (**) AT Translated Set 2 keyboard: Applying InputClass
 evdev keyboard catchall
 [ 16085.444] (**) AT Translated Set 2 keyboard: Applying InputClass
 keyboard-de
 [ 16085.444] (II) Loading /usr/lib64/xorg/modules/input/evdev_drv.so
 [ 16085.444] (**) AT Translated Set 2 keyboard: always reports core events
 [ 16085.444] (**) AT Translated Set 2 keyboard: Device: /dev/input/event4
 [ 16085.448] (--) AT Translated Set 2 keyboard: Found keys
 [ 16085.448] (II) AT Translated Set 2 keyboard: Configuring as keyboard
 [ 16085.448] (**) Option config_info
 udev:/sys/devices/platform/i8042/serio0/input/input4/event4
 [ 16085.448] (II) XINPUT: Adding extended input device AT Translated
 Set 2 keyboard (type: KEYBOARD)
 [ 16085.448] (**) Option xkb_rules evdev
 [ 16085.448] (**) Option xkb_model evdev
 [ 16085.448] (**) Option xkb_layout us
 [ 16085.448] (**) Option xkb_options terminate:ctrl_alt_bksp
 [ 16085.448] (II) XKB: Reusing cached keymap
 [ 16085.448] (II) config/udev: Adding input device SynPS/2 Synaptics
 TouchPad (/dev/input/event7)

 I even added the option xkb_layout, recompiled the whole stuff and so on.

 I'm using startx -- -logverbose, is that OK?

Hmm, yeah. You can try to up the level to -logverbose 10 or something
and get a ton of info.

--
Dan
___
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Your subscription address: arch...@mail-archive.com

Re: Evdev keyboard sends keycodes but no keysyms

[Dan Nicholson]

On Sun, Nov 14, 2010 at 8:19 PM, Peter Hutterer
peter.hutte...@who-t.net wrote:
 On Sun, Nov 14, 2010 at 02:11:25PM -0800, walt wrote:
 On 11/14/2010 09:11 AM, Simon Thum wrote:
 Hi all,
 
 yesterday I recompiled xorg, updating from a ca. 3 week old install
 using gentoo's live ebuilds. I went into an amusing bug which I narrowed
 down a bit.
 
 I'm having the following xorg.conf.d fragment:
 
 Section InputClass
          Identifier keyboard-de
          MatchIsKeyboard on
          Option XKBOptions terminate:ctrl_alt_bksp
          #Option XKBVariant nodeadkeys
          Option XKBLayout de
 EndSection
 
 Funny enough, invoking
 
 setxkbmap -rules evdev -layout de -variant nodeadkeys
 
 brings back my keyboard as intended!

 I notice that your Xorg log says

 [  4702.616] (**) Option xkb_rules evdev
 [  4702.616] (**) Option xkb_model evdev
 [  4702.616] (**) Option xkb_layout us    ???
 [  4702.616] (**) Option xkb_variant nodeadkeys
 [  4702.616] (**) Option xkb_options terminate:ctrl_alt_bksp

 yeah, I noticed this as well. there's no nodeadkeys variant for us, which
 would explain the NoSymbol issue. Now the real issue is why it doesn't take
 your de setting...

Running with -logverbose will give more details on the merging of
InputClass settings.

--
Dan
___
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Your subscription address: arch...@mail-archive.com

Re: libX11 configure.ac patch

[Dan Nicholson]

On Fri, Nov 5, 2010 at 3:35 AM, Frans Meulenbroeks
fransmeulenbro...@gmail.com wrote:
 Dear all,

 While trying to compile libX11 for nios2, I discovered that configure
 accidently thinks it is an os2 system (which is not the case).
 The failing code is a match on target_alias for *os2*. As my
 target_alias is nios2_linux, this also matches.
 I found this on 1.3.2 but verified that the same code is still present
 in git head.

 The patch below fixes this for me, but I can imagine people prefer to
 strengthen the match for os2 (not sure if changing *os2* to os2* will
 work, can't really verify that).

 In case further info is needed feel free to contact me directly. I am
 not on the list, just someone passing by to report a problem and
 solution.

 Best regards  keep up the good work!
 Frans

 Index: libX11-1.3.2/configure.ac
 ===
 --- libX11-1.3.2.orig/configure.ac      2010-11-05 10:30:33.825536983 +0100
 +++ libX11-1.3.2/configure.ac   2010-11-05 10:31:25.913899269 +0100
 @@ -202,6 +202,7 @@
  # arch specific things
  WCHAR32=1
  case $target_alias in
 +  nios2*) os2=false ;;
   *os2*) os2=true ; WCHAR32=0 ;;
   *) ;;
  esac

I think the reason that *os2* was used is because the test is against
$target_alias, and the os2 may be buried in the middle like
i386-pc-os2-emx. I see three possible solutions:

1. Change to $target_os, in which case you can just test os2*.

2. Leave it as $target_alias, but change the test to *-os2*.

3. Special case nios2* as you've done here since it will catch the cpu
type at the beginning.

I think 1 is the most correct since really what we're trying to do is
match the OS/2 operating system. Does the following work for you?

diff --git a/configure.ac b/configure.ac
index 5b79b43..6ec8bda 100644
--- a/configure.ac
+++ b/configure.ac
@@ -246,8 +246,8 @@ dnl AC_PATH_XTRA

 # arch specific things
 WCHAR32=1
-case $target_alias in
-  *os2*) os2=true ; WCHAR32=0 ;;
+case $target_os in
+  os2*) os2=true ; WCHAR32=0 ;;
   *) ;;
 esac
 AC_SUBST(WCHAR32)

Noticing now that this should really be testing $host_alias or
$host_os since that's what you're building the package for. The
$target* variables are really only applicable when you're building a
cross compiler or something like that. That's orthogonal, but should
be fixed.

--
Dan
___
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Your subscription address: arch...@mail-archive.com

Re: libX11 configure.ac patch

[Dan Nicholson]

On Fri, Nov 5, 2010 at 6:16 AM, Frans Meulenbroeks
fransmeulenbro...@gmail.com wrote:
 2010/11/5 Dan Nicholson dbn.li...@gmail.com:
 On Fri, Nov 5, 2010 at 3:35 AM, Frans Meulenbroeks
 fransmeulenbro...@gmail.com wrote:
 Dear all,

 While trying to compile libX11 for nios2, I discovered that configure
 accidently thinks it is an os2 system (which is not the case).
 The failing code is a match on target_alias for *os2*. As my
 target_alias is nios2_linux, this also matches.
 I found this on 1.3.2 but verified that the same code is still present
 in git head.

 The patch below fixes this for me, but I can imagine people prefer to
 strengthen the match for os2 (not sure if changing *os2* to os2* will
 work, can't really verify that).

 In case further info is needed feel free to contact me directly. I am
 not on the list, just someone passing by to report a problem and
 solution.

 Best regards  keep up the good work!
 Frans

 Index: libX11-1.3.2/configure.ac
 ===
 --- libX11-1.3.2.orig/configure.ac      2010-11-05 10:30:33.825536983 +0100
 +++ libX11-1.3.2/configure.ac   2010-11-05 10:31:25.913899269 +0100
 @@ -202,6 +202,7 @@
  # arch specific things
  WCHAR32=1
  case $target_alias in
 +  nios2*) os2=false ;;
   *os2*) os2=true ; WCHAR32=0 ;;
   *) ;;
  esac

 I think the reason that *os2* was used is because the test is against
 $target_alias, and the os2 may be buried in the middle like
 i386-pc-os2-emx. I see three possible solutions:

 1. Change to $target_os, in which case you can just test os2*.

 2. Leave it as $target_alias, but change the test to *-os2*.

 3. Special case nios2* as you've done here since it will catch the cpu
 type at the beginning.

 I think 1 is the most correct since really what we're trying to do is
 match the OS/2 operating system. Does the following work for you?

 diff --git a/configure.ac b/configure.ac
 index 5b79b43..6ec8bda 100644
 --- a/configure.ac
 +++ b/configure.ac
 @@ -246,8 +246,8 @@ dnl AC_PATH_XTRA

  # arch specific things
  WCHAR32=1
 -case $target_alias in
 -  *os2*) os2=true ; WCHAR32=0 ;;
 +case $target_os in
 +  os2*) os2=true ; WCHAR32=0 ;;
   *) ;;
  esac
  AC_SUBST(WCHAR32)

 Thanks for your quick reply!

 This works for me. Actually I did expect this, as my target_os is not
 os2* so I should get the default case.
 The key question is: does this work for os2 systems (and I cannot test that)

Me neither, but I think it should be safe. Clearly this is intended
for OS/2 the operating system.

 Noticing now that this should really be testing $host_alias or
 $host_os since that's what you're building the package for. The
 $target* variables are really only applicable when you're building a
 cross compiler or something like that. That's orthogonal, but should
 be fixed.

 That's ok. Didn't mention this, but actually this happens when cross
 compiling so I should be using the target_* vars as I am cross
 compiling a lib for the target.
 (nios2 is not that fast, you do not want to compile big packages like X on 
 it).

Technically, when cross compiling --target is only needed when you are
building a compiler. I.e., the system that you're targetting your code
to be created for. --host defines what system you'll be running the
binaries on.

http://www.gnu.org/software/automake/manual/automake.html#Cross_002dCompilation

Do you specify just --target when you build or also --host?

--
Dan
___
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Your subscription address: arch...@mail-archive.com

Re: jhBuild

[Dan Nicholson]

On Thu, Nov 4, 2010 at 2:23 AM, CN, Harsha SISPL harsha...@siemens.com wrote:
 Hi,



 Is there a way to provide DESTDIR option with jhbuild, default it installs
 in location specified by prefix.

I don't think there is, really. While you're building each package, it
expects to find the ones it depends on (headers/libraries) in their
final location. I think the best you can do is try running it in a
chroot, but that has its own issues. Otherwise, you'd need to handle
the packages like you're cross compiling them. I don't think jhbuild
is prepared for that.

--
Dan
___
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Your subscription address: arch...@mail-archive.com

Re: [ANNOUNCE] xorg-server 1.8.99.904

[Dan Nicholson]

On Thu, Jul 1, 2010 at 8:45 AM, Tiago Vignatti tiago.vigna...@nokia.com wrote:
 Hi!

 On Thu, Jul 01, 2010 at 03:40:50PM +0200, Keith Packard wrote:

 Not a huge number of changes this week; a couple of bug fixes, some
 server log cleanups and some Xephyr changes.

 I got gitdm working with xserver [0] and here are the results from 1.8.0 until
 1.8.9.904.

Wow, this is awesome! Thanks for doing that, Tiago.

snip

 - If my math is correct, the rate between review + tests + signoffs (386 + 31
  + 554) and commits made (441) is 2.2. In short, that's the average number of
  reviews made per patch that got commit.

Since we don't commit patches without a Signed-off-by, it seems that
just the Reviewed/Tested/Acked-by are more important on their own. For
instance, 386/441 = 88% of commits had a Reviewed-by is pretty
impressive.

 - the delta (302) between lines added and removed are small. I think this is
  perfectly understandable given the amount of clean-up we had (MAXSCREENS
  removal, *alloc, PCI stuff, etc) in 1.9 development against the features
  added.

 - 39% of changeset represents contributors not affiliated with any company
  (gitdm -u). Worth to note that Jamey and Mikhail made a huge amount of
  contribution and I counted as not affiliated - probably wrong.

  Maybe we can say that X development could survive in some way even not
  having any company directly contributing there.

 - Intel, Nokia, Red Hat, Oracle and Apple are on the top five. Other known
  companies that care about X and desktop like Google, Canonical and etc are
  far from those on the amount of contribution.

 - what else?


 Well, that are just some facts that I got quickly running gitdm here. I don't
 think that only the xserver represents all graphics development under X.Org
 community. It's just a portion of it and we would have to include DRI, Mesa,
 drivers, etc to get a more accurate analysis.

It would be cool to run it on Mesa. It will be mostly vmware, but
that's certainly a very active and significant part of the graphics
puzzle.

--
Dan
___
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Your subscription address: arch...@mail-archive.com

Re: Questions about X server abort

[Dan Nicholson]

On Wed, Jun 23, 2010 at 7:31 PM, 邓逸昕 bupt.dengyi...@gmail.com wrote:
 Hi Dan Nicholson :

  Glad to talk with you! I have a question to bother you about X server
 abort. My X server's version is xorg-server-1.8.1 on May 11st. However, if
 using the latest X server version, the problem still remain the same.

 Phenomena:
   When I run the XLIB tests like cpypln, it will call the
 ExaCheckCopyPlane in exa_unaccel.c. The X server reports  FinishAccess
 called without PrepareAccess for pixmap in exaFinishAccess. I found it the
 exaPrepareAccess(pPixmap-drawable, EXA_PREPARE_AUX_DEST) in
 exaCreatePixmap_driver  won't be executed at all. The judged condition if
 (pExaScr-fallback_counter) can't be met.

 Questions:
  The problem may occur in the EXA modules. While creating Pixmaps,
 it doesn't know the pixmap will be applied in exa_accel.c or exa_unaccel.c.
 Therefore the if (pExaScr-fallback_counter)  doesn't make sense.
   While cpypln destroys the pixmaps, it will do exaFinishAccess as
 the fallback_counter == 1. It lacks the balance of calling
 exaPrepareAccess and exaFinishAccess. So the X server aborts.
   Currently I have added the code in the exaFinishAccess in order to
 prevent the above issues.

     What do you think about the error? I look forward to your reply.
 Thank you!

The handling of exa and any errors are a property of the video driver
you're using. What driver are you using? Can you attach Xorg.0.log?
I've cc'd the xorg list since I really don't know exa.

--
Dan
___
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Your subscription address: arch...@mail-archive.com

Re: libXfont 1.4.2 build issue

[Dan Nicholson]

On Fri, Jun 25, 2010 at 2:55 AM, Mikhail Gusarov
dotted...@dottedmag.net wrote:

 Twas brillig at 11:46:12 25.06.2010 UTC+02 when wha...@bfs.de did gyre and 
 gimble:

  wh please do not drop txt support. txt is much more accessable/processable 
 that
  wh html. txt can always be read without special tools.

 lynx -dump

In fact, that's what the default xmlto txt backend does. See
/usr/share/xmlto/format/docbook/txt.

--
Dan
___
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Your subscription address: arch...@mail-archive.com

Re: restore from suspend to ram

[Dan Nicholson]

2010/6/8 Łukasz Maśko e...@yen.ipipan.waw.pl:
 Dnia wtorek, 8 czerwca 2010, Nigel Sollars napisał:
 My old gateway laptop has a Mobility x1400 its running Ubuntu 10.04LTS it
 does not have this issue but it does do something similar if the lid is
 closed ( activating the screen disable ) once the screen is out it will
 not come back on for love nor money.  To be honest though I suspect its
 more to do with a broken bios / acpi event that causes this.

 The kernel its using is 2.6.32-2 as per Ubuntu update.

 I have the same with my Dell D430, which has a Intel i945GM graphics.

 I've also noticed a problem with Suspend-to-RAM, after switching to kernel
 2.6.34 - after resuming from suspend, my screen starts to flicker randomly,
 not only under X, but also in the console (I'm using KMS). Restarting X
 doesn't work, the only way of getting rid of it is restarting the whole
 system.

On intel you can try installing intel-gpu-tools[1] and then using
intel_reg_dumper before and after suspend to see if some state is not
getting restored correctly. Also, asking on
intel-...@lists.freedesktop.org would help.

--
Dan

1. http://cgit.freedesktop.org/xorg/app/intel-gpu-tools/
___
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Your subscription address: arch...@mail-archive.com

Re: mouse gets stuck on second screen

[Dan Nicholson]

On Sat, Jun 5, 2010 at 2:11 PM, David Bridgham d...@froghouse.org wrote:
 I run a Debian system with two Radeon HD 2600 Pro video cards, each
 with two monitors.  Until a few months ago this was working fine.
 Then an update came in and Xorg started segfaulting on startup.  I
 found that if I arranged the two monitors on a given card horizontally
 instead of vertically, it stopped segfaulting but now had a new
 problem.  If I move the mouse cursor to the screen defined by the
 second video card, it can never come back to the first.  It gets stuck
 over there.

 It seems this must be something simple in my config file but I can not
 figure it out.  Any suggestions?  Thanks.

  -Dave

 Section ServerLayout
        Identifier     X.org Configured
 #       Screen      0  Screen0 0 0
 #       Screen      1  Screen1 Above Screen0
        Screen      0  Screen0
        Screen      1  Screen1 Below Screen0
        InputDevice    Mouse0 CorePointer
        InputDevice    Keyboard0 CoreKeyboard
 EndSection

So, this is zaphod mode with the radeonhd driver. Maybe you can try
using the radeon driver? I know there have been some fixes recently to
zaphod mode, although I don't know if that will fix the input issues.

--
Dan
___
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Your subscription address: arch...@mail-archive.com

Re: configuring a 3 button mouse.

[Dan Nicholson]

On Mon, Jun 7, 2010 at 12:21 PM, Geoffrey li...@serioustechnology.com wrote:
 I recently upgraded my Mandriva install and now it appears that my 3 button
 mouse is emulating a 2 button mouse as cut/paste only works when I select
 buttons 1 and 3, but not with button 2.

 The middle button is a wheel and scrolling does work with it, which leads to
 more confusion.

 This has always 'just worked' so it's been a while since I tried to
 configure this.  my xorg.conf looks right (to me):

 Section InputDevice
    Identifier Mouse1
    Driver mouse
    Option Protocol ExplorerPS/2
    Option Device /dev/mouse
    Option Emulate3Buttons
    Option Emulate3Timeout 50
    Option EmulateWheel
    Option EmulateWheelButton 2
 EndSection

 Any suggestions would be appreciated.

Can you the log so we can see what's going on? My guess is the device
isn't using the mouse driver like you think it is.

--
Dan
___
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Your subscription address: arch...@mail-archive.com

Re: configuring a 3 button mouse.

[Dan Nicholson]

On Mon, Jun 7, 2010 at 12:54 PM, Geoffrey li...@serioustechnology.com wrote:
 Dan Nicholson wrote:

 On Mon, Jun 7, 2010 at 12:21 PM, Geoffrey li...@serioustechnology.com
 wrote:

 I recently upgraded my Mandriva install and now it appears that my 3
 button
 mouse is emulating a 2 button mouse as cut/paste only works when I select
 buttons 1 and 3, but not with button 2.

 The middle button is a wheel and scrolling does work with it, which leads
 to
 more confusion.

 This has always 'just worked' so it's been a while since I tried to
 configure this.  my xorg.conf looks right (to me):

 Section InputDevice
   Identifier Mouse1
   Driver mouse
   Option Protocol ExplorerPS/2
   Option Device /dev/mouse
   Option Emulate3Buttons
   Option Emulate3Timeout 50
   Option EmulateWheel
   Option EmulateWheelButton 2
 EndSection

 Any suggestions would be appreciated.

 Can you the log so we can see what's going on? My guess is the device
 isn't using the mouse driver like you think it is.

 I think you're onto something.  I see this:

 (==) The core pointer device wasn't specified explicitly in the layout.
        Using the first mouse device.

 I've attached both my xorg.conf and the log for further insights.

 --
 Until later, Geoffrey

 I predict future happiness for America if they can prevent
 the government from wasting the labors of the people under
 the pretense of taking care of them.
 - Thomas Jefferson

 # nvidia-xconfig: X configuration file generated by nvidia-xconfig
 # nvidia-xconfig:  version 1.0  (buildmeis...@builder58)  Wed Dec  9
 16:34:26 PST 2009

 # Xorg configuration created by pyxf86config

 Section ServerLayout
    Identifier     Default Layout
    Screen      0  Screen0 0 0
    InputDevice    Mouse0 CorePointer
    InputDevice    Keyboard0 CoreKeyboard
 EndSection

 Section InputDevice

    # generated from default
    Identifier     Mouse0
    Driver         mouse
    Option         Protocol auto
    Option         Device /dev/input/mice
    Option         Emulate3Buttons no
    Option         ZAxisMapping 4 5
 EndSection

It looks like it's using the right settings, but now you have
Emulate3Buttons no. From your log:

(**) Option Protocol auto
(**) Mouse0: Device: /dev/input/mice
(**) Mouse0: Protocol: auto
(**) Option CorePointer
(**) Mouse0: Core Pointer
(**) Option Device /dev/input/mice
(**) Option Emulate3Buttons no
(**) Option ZAxisMapping 4 5
(**) Mouse0: ZAxisMapping: buttons 4 and 5
(**) Mouse0: Buttons: 9

Perhaps you should change that to Emulate3Buttons yes?

--
Dan
___
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Your subscription address: arch...@mail-archive.com

Re: mouse gets stuck on second screen

[Dan Nicholson]

On Mon, Jun 7, 2010 at 1:04 PM, David Bridgham d...@froghouse.org wrote:
 On 06/07/2010 03:22 PM, Dan Nicholson wrote:

 So, this is zaphod mode with the radeonhd driver. Maybe you can try
 using the radeon driver? I know there have been some fixes recently to
 zaphod mode, although I don't know if that will fix the input issues.



 Took me a bit to figure out zaphod mode.  I hadn't heard that term
 before.  I like.

 I tried the radeon driver and surprisingly, at least to me, it has
 exactly the same problem.  It also shows the same output on the two
 monitors on each video card but presumably I could figure that out if I
 played with it some.  However, the problem with the mouse becoming
 trapped on Screen1 once it goes there is just the same as with the
 radeonhd driver.

Hmm. Could very well be a problem in the server. I don't use zaphod
mode, but I understand it was broken for a long time. You might want
to file a bug, but hopefully someone can help you out here.

--
Dan
___
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Your subscription address: arch...@mail-archive.com

Re: xorg can't load qxl driver

[Dan Nicholson]

On Mon, Jun 7, 2010 at 3:37 PM, brian bri...@io.com wrote:

 I followed the instructions here:
 http://www.cs.rug.nl/~jurjen/ApprenticesNotes/ch28s06.html

 snip

 Where is the qxl driver being installed? Is it the same place that the
 server expects to find drivers? The normal place would be something
 like /usr/lib/xorg/modules/drivers if you're on x86. I see the
 instructions there are instructing you to pass --libdir=/usr/lib64
 when building qxl. Don't do that if you're not on x86_64.

 On the other hand, I don't know why you don't have the void input
 driver. Maybe it's not installed. I don't know the debian/ubuntu
 package name, but it might be xserver-xorg-input-void.

 Anyway, your log would help.

 Thanks Dan, that is a start.  Since the instructions didn't mention
 putting the drivers anywhere special I just put them in my home folder.
 Please excuse any dumb mistakes, I'm kind of new to this.   I went ahead
 and remade the drivers in the /usr/lib/xorg/modules/drivers minus the
 --libdir=/usr/lib64 since I'm using 32 bit ubuntu.

You can actually put them where you want if you tell the server where
to find them. See the ModulePath option in xorg.conf(5). Both ways
work fine, though.

 I also installed the void driver, which you had the correct name for.
 Now when I stop and start gdm it still puts me in low graphics mode but
 says it cannot detect my screen, video adapter, and input device settings.
  Here is the last section of my xorg log, which I hope has all the
 relevant info:

Can you attach the whole log? Sometimes there's interesting things
that happen earlier in the initialization.

 ha...@citadel:~$ sudo tail -30 /var/log/Xorg.0.log
 (II) qxl(0): Device version 0.0
 (II) qxl(0): Compression level 0, log level 0
 (II) qxl(0): Currently using mode #-1, list at 0x34
 (II) qxl(0): 14357 io pages at 0x0
 (II) qxl(0): 8294400 byte draw area at 0x3815b68
 (II) qxl(0): RAM header offset: 0x3ffeb68
 (II) qxl(0): Correct RAM signature 41525851
 (II) qxl(0): Monitor0: Using hsync range of 31.50-80.00 kHz
 (II) qxl(0): Monitor0: Using vrefresh range of 50.00-70.00 Hz
 (II) qxl(0): Clock range:  10.00 to 165.00 MHz
 (II) qxl(0): Not using default mode 640x350 (no mode of this name)
 (II) qxl(0): Not using default mode 320x175 (bad mode
 clock/interlace/doublescan)
 (II) qxl(0): Not using default mode 640x400 (no mode of this name)
 (II) qxl(0): Not using default mode 320x200 (bad mode
 clock/interlace/doublescan)
 (II) qxl(0): Not using default mode 720x400 (no mode of this name)
 (II) qxl(0): Not using default mode 360x200 (bad mode
 clock/interlace/doublescan)

 Backtrace:
 0: /usr/bin/X(xorg_backtrace+0x3b) [0x8133d6b]
 1: /usr/bin/X(xf86SigHandler+0x55) [0x80c7d35]
 2: [0xae9400]
 3: /usr/bin/X(xf86InitialCheckModeForDriver+0x1ee) [0x80da28e]
 4: /usr/bin/X(xf86ValidateModes+0xe91) [0x80dc011]
 5: /usr/lib/xorg/modules/drivers//qxl_drv.so [0x28ade4]
 6: /usr/bin/X(InitOutput+0x4e9) [0x80b05b9]
 7: /usr/bin/X(main+0x1cb) [0x807234b]
 8: /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe6) [0x126b56]
 9: /usr/bin/X [0x80719c1]
 Saw signal 11.  Server aborting.
  ddxSigGiveUp: Closing log

Looks like you got a segfault (signal 11 with a partial backtrace).
I'm not sure the reason why, but this is probably going to take
someone familiar with qxl.

--
Dan
___
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Your subscription address: arch...@mail-archive.com

Re: xorg can't load qxl driver

[Dan Nicholson]

On Mon, Jun 7, 2010 at 5:13 PM, brian bri...@io.com wrote:

 Can you attach the whole log? Sometimes there's interesting things
 that happen earlier in the initialization.

 Sure, here goes:
 X.Org X Server 1.6.4
 Release Date: 2009-9-27
 X Protocol Version 11, Revision 0
 Build Operating System: Linux 2.6.24-27-server i686 Ubuntu
 Current Operating System: Linux Citadel 2.6.31-21-generic #59-Ubuntu SMP
 Wed Mar 24 07:28:56 UTC 2010 i686
 Kernel command line: BOOT_IMAGE=/vmlinuz-2.6.31-21-generic
 root=UUID=24d25872-4c39-431a-9586-cd2c14807610 ro quiet splash
 Build Date: 06 May 2010  09:30:46PM
 xorg-server 2:1.6.4-2ubuntu4.3 (buildd@)
        Before reporting problems, check http://wiki.x.org
        to make sure that you have the latest version.
 Markers: (--) probed, (**) from config file, (==) default setting,
        (++) from command line, (!!) notice, (II) informational,
        (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
 (==) Log file: /var/log/Xorg.0.log, Time: Mon Jun  7 17:26:24 2010
 (==) Using config file: /etc/X11/xorg.conf
 (==) ServerLayout X.org Configured
 (**) |--Screen Screen0 (0)
 (**) |   |--Monitor Monitor0
 (**) |   |--Device Card0
 (**) |--Input Device Mouse0
 (**) |--Input Device Keyboard0
 (==) Automatically adding devices
 (==) Automatically enabling devices
 (WW) The directory /usr/share/fonts/X11/cyrillic does not exist.
        Entry deleted from font path.
 (WW) The directory /usr/share/fonts/X11/cyrillic does not exist.
        Entry deleted from font path.
 (**) FontPath set to:
        /usr/share/fonts/X11/misc,
        /usr/share/fonts/X11/100dpi/:unscaled,
        /usr/share/fonts/X11/75dpi/:unscaled,
        /usr/share/fonts/X11/Type1,
        /usr/share/fonts/X11/100dpi,
        /usr/share/fonts/X11/75dpi,
        /var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType,
        built-ins,
        /usr/share/fonts/X11/misc,
        /usr/share/fonts/X11/100dpi/:unscaled,
        /usr/share/fonts/X11/75dpi/:unscaled,
        /usr/share/fonts/X11/Type1,
        /usr/share/fonts/X11/100dpi,
        /usr/share/fonts/X11/75dpi,
        /var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType,
        built-ins
 (**) ModulePath set to /usr/lib/xorg/modules
 (WW) AllowEmptyInput is on, devices using drivers 'kbd', 'mouse' or
 'vmmouse' will be disabled.
 (WW) Disabling Keyboard0
 (II) Loader magic: 0x3bc0
 (II) Module ABI versions:
        X.Org ANSI C Emulation: 0.4
        X.Org Video Driver: 5.0
        X.Org XInput driver : 4.0
        X.Org Server Extension : 2.0
 (II) Loader running on linux
 (--) using VT number 7

 (--) PCI:*(0:0:3:0) 1b36:0100:1af4:1100 Red Hat, Inc. rev 1, Mem @
 0xc400/67108864, 0xc800/4096, 0xc8002000/8192, I/O @ 0xc050/8
 (II) Open ACPI successful (/var/run/acpid.socket)
 (II) System resource ranges:
        [0] -1  0       0x - 0x (0x1) MX[B]
        [1] -1  0       0x000f - 0x000f (0x1) MX[B]
        [2] -1  0       0x000c - 0x000e (0x3) MX[B]
        [3] -1  0       0x - 0x0009 (0xa) MX[B]
        [4] -1  0       0x - 0x (0x1) IX[B]
        [5] -1  0       0x - 0x (0x1) IX[B]
 (II) extmod will be loaded. This was enabled by default and also
 specified in the config file.
 (II) dbe will be loaded. This was enabled by default and also specified
 in the config file.
 (II) glx will be loaded. This was enabled by default and also specified
 in the config file.
 (II) record will be loaded. This was enabled by default and also
 specified in the config file.
 (II) dri will be loaded. This was enabled by default and also specified
 in the config file.
 (II) dri2 will be loaded. This was enabled by default and also specified
 in the config file.
 (II) LoadModule: dbe
 (II) Loading /usr/lib/xorg/modules/extensions//libdbe.so
 (II) Module dbe: vendor=X.Org Foundation
        compiled for 1.6.4, module version = 1.0.0
        Module class: X.Org Server Extension
        ABI class: X.Org Server Extension, version 2.0
 (II) Loading extension DOUBLE-BUFFER
 (II) LoadModule: extmod
 (II) Loading /usr/lib/xorg/modules/extensions//libextmod.so
 (II) Module extmod: vendor=X.Org Foundation
        compiled for 1.6.4, module version = 1.0.0
        Module class: X.Org Server Extension
        ABI class: X.Org Server Extension, version 2.0
 (II) Loading extension MIT-SCREEN-SAVER
 (II) Loading extension XFree86-VidModeExtension
 (II) Loading extension XFree86-DGA
 (II) Loading extension DPMS
 (II) Loading extension XVideo
 (II) Loading extension XVideo-MotionCompensation
 (II) Loading extension X-Resource
 (II) LoadModule: glx
 (II) Loading /usr/lib/xorg/modules/extensions//libglx.so
 (II) Module glx: vendor=X.Org Foundation
        compiled for 1.6.4, module version = 1.0.0
        ABI class: X.Org Server Extension, version 2.0
 (==) AIGLX enabled
 (II) Loading extension GLX
 (II) LoadModule: record
 (II) Loading /usr/lib/xorg/modules/extensions//librecord.so
 

Re: configuring a 3 button mouse.

[Dan Nicholson]

On Mon, Jun 7, 2010 at 5:26 PM, Geoffrey li...@serioustechnology.com wrote:
 Sergio Monteiro Basto wrote:

 On Mon, Jun 7, 2010 at 12:21 PM, Geoffrey
 li...@serioustechnology.com
 wrote:

 I recently upgraded my Mandriva install and now it appears that my 3
 button
 mouse is emulating a 2 button mouse as cut/paste only works when I
 select
 buttons 1 and 3, but not with button 2.

 The middle button is a wheel and scrolling does work with it, which
 leads
 to
 more confusion.

 wheel work, and click not ? hum ... the middle button not working at
 all ?
 to test it, for example, use middle button on links of Firefox, opens
 links ?

 Wheel scrolls, but button does nothing on links or anything else.

 (**) Option Protocol auto
 (**) Mouse0: Device: /dev/input/mice
 (**) Mouse0: Protocol: auto
 (**) Option CorePointer
 (**) Mouse0: Core Pointer
 (**) Option Device /dev/input/mice
 (**) Option Emulate3Buttons no
 (**) Option ZAxisMapping 4 5
 (**) Mouse0: ZAxisMapping: buttons 4 and 5
 (**) Mouse0: Buttons: 9

 seems correct , may be is not X fault ...

 What else could it be???  I might hook this mouse up to another linux box
 and see if it does the same thing.

I don't think it's the driver emulating 3 buttons. Looking at the old
mouse source, it should be giving you a message like (**) Mouse0:
Emulate3Buttons, Emulate3Timeout: 50.

Can you run xev and look for the what codes it gives you when you
press the middle button and left+middle?

--
Dan
___
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Your subscription address: arch...@mail-archive.com

Re: Transition from HAL to udev - mouse config

[Dan Nicholson]

On Thu, May 13, 2010 at 11:45 PM, Nikos Chantziaras rea...@arcor.de wrote:
 I had the following HAL configuration for my mouse in X.Org server 1.7 for a
 500DPI mouse:

 
 match key=info.capabilities contains=input.mouse
 merge key=input.x11_options.AccelerationProfile
       type=string2/merge
 merge key=input.x11_options.AdaptiveDeceleration
       type=string2/merge
 merge key=input.x11_options.ExpectedRate type=string500/merge
 merge key=input.x11_options.FilterHalflife type=string5/merge
 merge key=input.x11_options.FilterChainProgression
       type=string2/merge
 merge key=input.x11_options.VelocityCoupling
       type=string0.15/merge
 merge key=input.x11_options.FilterChainLength type=string8/merge
 merge key=input.x11_options.Softening type=stringtrue/merge
 

 With X.Org server 1.8 and HAL disabled, how to I configure the above?

cat  /etc/X11/xorg.conf.d/90-mouse.conf  EOF
Section InputClass
Identifier My Mouse Tweaks
Option AccelerationProfile 2
Option AdaptiveDeceleration 2
...
EndSection
EOF

See the InputClass section in xorg.conf(5).

--
Dan
___
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg

Re: getting device path or sysfs name of input device

[Dan Nicholson]

On Mon, May 10, 2010 at 03:07:04PM +1000, Peter Hutterer wrote:
 On Sun, May 09, 2010 at 09:50:47PM -0700, Alan Coopersmith wrote:
  On 5/9/2010 9:00 AM, John R. wrote:
  On 05/09/10 08:41, Tias wrote:
  
  [snip]
  
  I want to make the calibration permanent, and not just applied when the
  program is run.
  
  I am not an xorg developer so cannot assist with your technical questions.
  
  One of the other options you mention is adding calibration info to a
  xorg.conf.d file.  It share a common disadvantage with udev method in
  that it requires write access to files generally written to by root.
  
  xorg.conf.d will be far more portable than udev though, if you care
  about users of non-Linux kernels such as the BSD's or OpenSolaris.
 
 And we really don't recommend configuring X through udev. If udev rules are
 necessary, use them to tag devices only. The specific configuration then
 goes into the xorg.conf.
 
 Example I'm working on atm:
 Some touchpads have a less-than-ideal button positioning. This affects some
 specific models so you can use udev (or another config backend) to assign a
 touchpad_overlapping_buttons tag to those devices.
 
 Then in the xorg.conf, you can match this to whatever specific configuration
 you require for this kind of touchpads.

FWIW, I have a patchset to add PnP and USB ID matching in InputClass.
Basically, I want to be able to convert the existing synaptics and wacom
fdi files to InputClass, and they rely on PnP at least.

--
Dan
___
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg

Re: no screens found problem

[Dan Nicholson]

2010/4/20 Gökçe ÖZDEMİR gozde...@aselsan.com.tr:
 Hi,

 We are using Montavista PRO 5.0.24 on our Advantech's AIMB-766 model target 
 PC. Its chipset is Intel Q35. Graphics module is embedded on this chipset 
 (Intel GMA 3100)

 We would like to run X11 to have graphic support, but when we try startx 
 command it is giving the following error (whole log also attached)

 (EE) No devices detected.
 Fatal server error:
 no screens found

 Montavista PRO5.0.24 has X Window System Version 6.8.2 Release Date: 9 
 February 2005.
 And it seems since this is an pretty old version it does not have the support 
 for our graphic card module.

 We tried configurations for generic VESA and VGA by using xorgconfig command 
 but get the same error.

 What do you suggest? Can we add our graphic card support to current X11 
 version of our operating system, how?
 Or shall we update the x Window system of the Montavista, and how?

The intel q35 is much too new to work on xorg 6.8.2. Probably your
best bet is to get the vesa driver working. Read the output of the log
file to ensure that the Device section referencing Driver vesa is
being used. You can also try running the server with -logverbose n
where n is greater than 3 to get some more information.

Updating to a newer Xorg might be a challenge, but newer releases of
the intel driver do support that graphics hardware.

--
Dan
___
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg

Re: xorg-server may use dri.pc?

[Dan Nicholson]

On Thu, Apr 8, 2010 at 2:39 AM,  melodra...@online.de wrote:
 hello

 just for the case that you did not recognize it: mesa ships the file dri.pc 
 for a longer time now. xorg-server could recognize it and drop the need for 
 --with-dri-driver-path. below is the content of the file on my system:

 prefix=/usr
 exec_prefix=${prefix}
 libdir=/usr/lib
 includedir=/usr/include
 dridriverdir=/usr/lib/dri

 Name: dri
 Description: Direct Rendering Infrastructure
 Version: 7.8.1
 Requires.private: libdrm = 2.4.15
 Cflags: -I${includedir}

Yeah, I've been meaning to do that and haven't got around to it. I
don't remember when dridriverdir got added, but it seems like we
demand a very new dri.pc anyway. Thanks for the reminder.

--
Dan
___
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg

Re: [ANNOUNCE] xorg-server 1.8.0

[Dan Nicholson]

On Fri, Apr 2, 2010 at 2:29 PM, Dan Nicholson dbn.li...@gmail.com wrote:
 On Fri, Apr 2, 2010 at 2:25 PM, Julien Cristau jcris...@debian.org wrote:
 On Fri, Apr  2, 2010 at 14:10:47 -0700, Dan Nicholson wrote:

 On Fri, Apr 02, 2010 at 01:20:26PM -0700, Keith Packard wrote:
  On Fri, 2 Apr 2010 21:01:30 +0200, Julien Cristau jcris...@debian.org 
  wrote:
 
   And I'll be using /usr/lib/X11/xorg.conf.d/ because using /etc for the
   default make my xserver work snippets just seems wrong (and /usr
   allows me to make sure they're in sync with the packages, not conflated
   with configuration which is the admin's domain).
 
  Yeah, that's why I picked the 'secondary' path supported by the server
  so that a directory in /etc/X11 would completely override these files.
 
  Sounds like we need to fix the server config file search path to look in
  a sensible place rather than $(prefix)/etc/X11

 This is untested, but I think the patch below is all it would take to
 add support for a second system directory in $prefix/lib/X11 with
 lowest priority.

 This is already in {USER,ROOT}_CONFIGDIRPATH, shouldn't it be removed
 from there if we add a new search path?

 Yeah, probably. It was more of a proof of concept patch. Now would be
 the best time to look at those standard search paths and make them
 sane. There's no real reason to repeat the nonsense in the xorg.conf
 searching.

I posted a patch series which addresses most of these shortcomings, I
think. See 1270312431-11197-1-git-send-email-dbn.li...@gmail.com.

http://lists.freedesktop.org/archives/xorg-devel/2010-April/006846.html

Let me know what you think.

--
Dan
___
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg

Re: [ANNOUNCE] xorg-server 1.8.0

[Dan Nicholson]

On Fri, Apr 2, 2010 at 1:53 AM, Arkadiusz Miskiewicz ar...@maven.pl wrote:
 On Friday 02 of April 2010, Keith Packard wrote:
 The X.org X server 1.8.0 is now available. It's pretty close to RC2,
 with some XQuartz and Cygwin/X changes, and some various input cleanups.

 One other notable change since RC3 is that udev is now the default input
 device autoconfiguration mechanism where available, and the server
 installs a 10-evdev.conf file to make sure you get input devices after
 installing the new server.

 How to get it working with latest released udev 151 ? No input device was 
 added,
 so my keyboard/mouse doesn't work.

 [  1374.915] (II) intel(0): Setting screen physical size to 444 x 277
 [  1374.974] (II) config/udev: Adding input device Power Button 
 (/dev/input/event3)
 [  1374.974] (EE) No input driver/identifier specified (ignoring)

Can you post the rest of the log? It should be picking up the
InputClass settings from the installed xorg.conf.d/10-evdev.conf. See
the INPUTCLASS section in xorg.conf(5). They're basically like the fdi
stubs used with the hal backend.

--
Dan
___
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg

Re: [ANNOUNCE] xorg-server 1.8.0

[Dan Nicholson]

On Fri, Apr 2, 2010 at 10:03 AM, Keith Packard kei...@keithp.com wrote:

 Can you post the rest of the log? It should be picking up the
 InputClass settings from the installed xorg.conf.d/10-evdev.conf. See
 the INPUTCLASS section in xorg.conf(5). They're basically like the fdi
 stubs used with the hal backend.

 Yeah, one possibility is that you have an existing /etc/X11/xorg.conf.d
 directory which will cause the X server to skip everything in
 $(prefix)/etc/X11/xorg.conf.d and thus miss the 10-evdev.conf file.

 I'm not entirely sure that using only one xorg.conf.d directory is the
 right plan.

It might be hard to make it do the right thing with the command line
-configdir option, but all that code is pretty goofy and I would guess
not used much anymore. But as long as all the files end up in one
xorg.conf.d, the server will keep looking along all the myriad paths
detailed in xorg.conf(5) till it finds one.

Here's what I think would be more sane (assuming --sysconfdir=/etc):

xorg.conf:
1. For root, full path from -config
2. For any user, /etc/X11 + path basename from -config
3. /etc/X11/xorg.conf

xorg.conf.d:
1. For root, full path from -configdir
2. For any user, /etc/X11 + path basename from -configdir
3. /etc/X11/xorg.conf.d

Export the default in xorg-server.pc:
confdir=${sysconfdir}/X11/xorg.conf.d

Then it's straightforward to know where the right location is.

--
Dan
___
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg

Re: [ANNOUNCE] xorg-server 1.8.0

[Dan Nicholson]

On Fri, Apr 02, 2010 at 01:20:26PM -0700, Keith Packard wrote:
 On Fri, 2 Apr 2010 21:01:30 +0200, Julien Cristau jcris...@debian.org wrote:
 
  And I'll be using /usr/lib/X11/xorg.conf.d/ because using /etc for the
  default make my xserver work snippets just seems wrong (and /usr
  allows me to make sure they're in sync with the packages, not conflated
  with configuration which is the admin's domain).
 
 Yeah, that's why I picked the 'secondary' path supported by the server
 so that a directory in /etc/X11 would completely override these files.
 
 Sounds like we need to fix the server config file search path to look in
 a sensible place rather than $(prefix)/etc/X11

This is untested, but I think the patch below is all it would take to
add support for a second system directory in $prefix/lib/X11 with
lowest priority.

--
Dan

diff --git a/hw/xfree86/common/xf86Config.c b/hw/xfree86/common/xf86Config.c
index 718a078..06a3fa0 100644
--- a/hw/xfree86/common/xf86Config.c
+++ b/hw/xfree86/common/xf86Config.c
@@ -112,6 +112,10 @@ extern DeviceAssocRec mouse_assoc;
%P/lib/X11/%X.%H, %P/lib/X11/%X-%M, \
%P/lib/X11/%X
 #endif
+#ifndef SYS_CONFIGDIRPATH
+#define SYS_CONFIGDIRPATH  %P/lib/X11/%X.%H, %P/lib/X11/%X-%M, \
+   %P/lib/X11/%X
+#endif
 #ifndef PROJECTROOT
 #define PROJECTROOT/usr/X11R6
 #endif
@@ -2429,7 +2433,7 @@ checkInput(serverLayoutPtr layout, Bool implicit_layout) {
 ConfigStatus
 xf86HandleConfigFile(Bool autoconfig)
 {
-const char *filename, *dirname;
+const char *filename, *dirname, *sysdirname;
 char *filesearch, *dirsearch;
 MessageType filefrom = X_DEFAULT;
 MessageType dirfrom = X_DEFAULT;
@@ -2452,6 +2456,8 @@ xf86HandleConfigFile(Bool autoconfig)
dirfrom = X_CMDLINE;
 
xf86initConfigFiles();
+   sysdirname = xf86openConfigDirFiles(SYS_CONFIGDIRPATH, NULL,
+   PROJECTROOT);
dirname = xf86openConfigDirFiles(dirsearch, xf86ConfigDir, PROJECTROOT);
filename = xf86openConfigFile(filesearch, xf86ConfigFile, PROJECTROOT);
if (filename) {
@@ -2472,6 +2478,9 @@ xf86HandleConfigFile(Bool autoconfig)
Unable to locate/open config directory: \%s\\n,
xf86ConfigDir);
}
+   if (sysdirname)
+   xf86MsgVerb(X_DEFAULT, 0, Using system config directory: \%s\\n,
+   sysdirname);
if (!filename  !dirname)
return CONFIG_NOFILE;
 }

___
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg

Re: [ANNOUNCE] xf86-input-synaptics 1.2.2

[Dan Nicholson]

2010/3/25 Peter Hutterer peter.hutte...@who-t.net:
 Only two minor fixes for the stable 1.2 series. This version will work with
 the upcoming 1.8 X server release though you _must_ recompile, the ABI has
 been bumped.
 If you plan to use synaptics 1.2.2 with server 1.8, the following
 config snippet is recommended in /etc/xorg.conf.d/10-synaptics.conf:

 Section InputClass
        Identifier touchpad catchall
        Driver synaptics
        MatchIsTouchpad on
        MatchDevicePath /dev/input/event*
 EndSection

Maybe we should ship this in the tarball and/or install it like evdev
on xserver-1.8+. Also, do we need to limit to /dev/input/event*
devices? Unlike evdev, synaptics is used on multiple platforms that
probably don't have the same device layout. I think it's safe to just
have MatchIsTouchpad and let later rules sort out when that should not
be synaptics.

--
Dan
___
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg

Re: Missing symbol error when building X.org from git

[Dan Nicholson]

On Thu, Mar 18, 2010 at 9:12 PM, Joel Feiner jafei...@gmail.com wrote:
 On Thu, Mar 18, 2010 at 4:58 PM, Dan Nicholson dbn.li...@gmail.com wrote:

 On Thu, Mar 18, 2010 at 12:41 PM, Joel Feiner jafei...@gmail.com wrote:
  On Thu, Mar 18, 2010 at 3:32 PM, Dan Nicholson dbn.li...@gmail.com
  wrote:
 
  On Thu, Mar 18, 2010 at 10:54 AM, Joel Feiner jafei...@gmail.com
  wrote:
   The error that comes up is this:
   libtool: link: gcc -DHAVE_DMX_CONFIG_H -DHAVE_DIX_CONFIG_H -Wall
   -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes
   -Wmissing-declarations -Wnested-externs -fno-strict-aliasing
   -Wbad-function-cast -Wformat=2 -Wold-style-definition
   -Wdeclaration-after-statement -D_BSD_SOURCE -DHAS_FCHOWN
   -DHAS_STICKY_DIR_BIT -I/home//xbuild/out/include/pixman-1
   -I/usr/include/freetype2 -I../../include -I../../include -I../../Xext
   -I../../composite -I../../damageext -I../../xfixes -I../../Xi
   -I../../mi
   -I../../miext/shadow -I../../miext/damage -I../../render
   -I../../randr
   -I../../fb -fvisibility=hidden -I../../hw/xfree86/dixmods/extmod
   -I/home//xbuild/out/include/libdrm -I/usr/include/freetype2 -O2
   -mtune=native -march=native -pipe -fomit-frame-pointer -rdynamic -o
   Xdmx
   dmx.o dmxcb.o dmxcmap.o dmxcursor.o dmxdpms.o dmxextension.o
   dmxfont.o
   dmxgc.o dmxgcops.o dmxinit.o dmxinput.o dmxlog.o dmxpict.o
   dmxpixmap.o
   dmxprop.o dmxscrinit.o dmxshadow.o dmxstat.o dmxsync.o dmxvisual.o
   dmxwindow.o miinitext.o fbcmap_mi.o panoramiX.o dmx_glxvisuals.o
    -L/home//xbuild/out/lib64 ../../fb/.libs/libfb.a
   ../../mi/.libs/libmi.a
   ../../render/.libs/librender.a ../../Xi/.libs/libXi.a
   ../../xkb/.libs/libxkb.a ../../xkb/.libs/libxkbstubs.a
   ../../miext/shadow/.libs/libshadow.a
   ../../miext/damage/.libs/libdamage.a
   ../../Xext/.libs/libXext.a ../../dix/.libs/libmain.a
   ../../dix/.libs/libdix.a ../../config/.libs/libconfig.a
   /usr/lib64/libhal.so
   /usr/lib64/libdbus-1.so ../../os/.libs/libos.a
   /usr/lib64/libgcrypt.so
   -L/usr/lib64 /usr/lib64/libgpg-error.so
   ../../xfixes/.libs/libxfixes.a
   glxProxy/libglxproxy.a input/libdmxinput.a config/libdmxconfig.a
   /home//xbuild/out/lib64/libXmuu.so /usr/lib64/libXrender.so
   /usr/lib64/libX11.so /usr/lib64/libxcb.so /usr/lib64/libXau.so
   /home//xbuild/out/lib64/libXfixes.so
   /home//xbuild/out/lib64/libXi.so
   /home//xbuild/out/lib64/libXext.so
   /home//xbuild/out/lib64/libX11.so
   /home//xbuild/out/lib64/libxcb.so
   /usr/lib64/libXdmcp.so -ldl /home//xbuild/out/lib64/libXfont.so
   /usr/lib64/libfreetype.so /home//xbuild/out/lib64/libfontenc.so
   -lz
   /home//xbuild/out/lib64/libXau.so
   /home//xbuild/out/lib64/libpixman-1.so
   /home//xbuild/out/lib64/libXdmcp.so -lm -lrt -Wl,-rpath
   -Wl,/home//xbuild/out/lib64 -Wl,-rpath
   -Wl,/home//xbuild/out/lib64
  
   /home//xbuild/out/lib64/libXi.so: undefined reference to
   `XESetWireToEventCookie'
  
   /home//xbuild/out/lib64/libXi.so: undefined reference to
   `XESetCopyEventCookie'
   What appears to be happening, I think, is that it is getting
   libraries
   like
   libXrender and so on from /usr/lib64 instead of my build directory.
    I'm
   not
   sure why libtool is doing this.  I have my PKG_CONFIG_PATH set to my
   local
   build package config path (/home//xbuild/out/lib64/pkgconfig) and
   LD_LIBRARY_PATH is also set to that (modulo the pkgconfig part).  I
   had
   also
   built the whole get up without using LD_LIBRARY_PATH.  Same results.
    The
   only two modules that have this problem are pixman and xserver.
    Pixman
   I
   worked around by passing --disable-gtk to ./configure, since that was
   the
   part of the build that was failing.  For xserver, it appears to be
   dmx
   that's failing.
 
  If I had to guess, the /usr/lib64 is getting hardcoded into one of the
  .la libtool archives installed in /home. Can you do grep /usr/lib64
  /home//xbuild/out/lib64/*.la? Maybe there's a problem with module
  ordering in xorg.modules. Not sure if that's what's causing the
  reference errors, though.
 
  --
  Dan
 
  I actually did grep for /usr/lib64 in my ~/xbuild (where the source and
  output trees live) and removed all references in the libtool archives
  (and
  even in libtool itself!).  It didn't make a difference.

 Next time can you record what those references were? That would help
 solve this problem.

 They are now attached.  I stripped out some obvious irrelevant lines (like
 /usr/lib64/dbus*).  It's down to 254 lines, which hopefully shouldn't be too
 much to handle.
 I was not where I could go back to my Linux installation when I sent the 2nd
 email.

  Somehow libtool
  found those libraries again.  Note that it *has* found some of the
  libraries
  in the right place and that's the most confusing part.  I'm not on Linux
  right now, so I can't try diddling with xorg.modules, but I'll try that
  again later this evening or tomorrow

Re: Missing symbol error when building X.org from git

[Dan Nicholson]

On Fri, Mar 19, 2010 at 8:17 AM, Joel Feiner jafei...@gmail.com wrote:
 On Fri, Mar 19, 2010 at 10:05 AM, Dan Nicholson dbn.li...@gmail.com wrote:

 On Thu, Mar 18, 2010 at 9:12 PM, Joel Feiner jafei...@gmail.com wrote:
  On Thu, Mar 18, 2010 at 4:58 PM, Dan Nicholson dbn.li...@gmail.com
  wrote:
 
  On Thu, Mar 18, 2010 at 12:41 PM, Joel Feiner jafei...@gmail.com
  wrote:
   On Thu, Mar 18, 2010 at 3:32 PM, Dan Nicholson dbn.li...@gmail.com
   wrote:
  
   On Thu, Mar 18, 2010 at 10:54 AM, Joel Feiner jafei...@gmail.com
   wrote:
The error that comes up is this:
libtool: link: gcc -DHAVE_DMX_CONFIG_H -DHAVE_DIX_CONFIG_H -Wall
-Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes
-Wmissing-declarations -Wnested-externs -fno-strict-aliasing
-Wbad-function-cast -Wformat=2 -Wold-style-definition
-Wdeclaration-after-statement -D_BSD_SOURCE -DHAS_FCHOWN
-DHAS_STICKY_DIR_BIT -I/home//xbuild/out/include/pixman-1
-I/usr/include/freetype2 -I../../include -I../../include
-I../../Xext
-I../../composite -I../../damageext -I../../xfixes -I../../Xi
-I../../mi
-I../../miext/shadow -I../../miext/damage -I../../render
-I../../randr
-I../../fb -fvisibility=hidden -I../../hw/xfree86/dixmods/extmod
-I/home//xbuild/out/include/libdrm -I/usr/include/freetype2
-O2
-mtune=native -march=native -pipe -fomit-frame-pointer -rdynamic
-o
Xdmx
dmx.o dmxcb.o dmxcmap.o dmxcursor.o dmxdpms.o dmxextension.o
dmxfont.o
dmxgc.o dmxgcops.o dmxinit.o dmxinput.o dmxlog.o dmxpict.o
dmxpixmap.o
dmxprop.o dmxscrinit.o dmxshadow.o dmxstat.o dmxsync.o dmxvisual.o
dmxwindow.o miinitext.o fbcmap_mi.o panoramiX.o dmx_glxvisuals.o
 -L/home//xbuild/out/lib64 ../../fb/.libs/libfb.a
../../mi/.libs/libmi.a
../../render/.libs/librender.a ../../Xi/.libs/libXi.a
../../xkb/.libs/libxkb.a ../../xkb/.libs/libxkbstubs.a
../../miext/shadow/.libs/libshadow.a
../../miext/damage/.libs/libdamage.a
../../Xext/.libs/libXext.a ../../dix/.libs/libmain.a
../../dix/.libs/libdix.a ../../config/.libs/libconfig.a
/usr/lib64/libhal.so
/usr/lib64/libdbus-1.so ../../os/.libs/libos.a
/usr/lib64/libgcrypt.so
-L/usr/lib64 /usr/lib64/libgpg-error.so
../../xfixes/.libs/libxfixes.a
glxProxy/libglxproxy.a input/libdmxinput.a config/libdmxconfig.a
/home//xbuild/out/lib64/libXmuu.so /usr/lib64/libXrender.so
/usr/lib64/libX11.so /usr/lib64/libxcb.so /usr/lib64/libXau.so
/home//xbuild/out/lib64/libXfixes.so
/home//xbuild/out/lib64/libXi.so
/home//xbuild/out/lib64/libXext.so
/home//xbuild/out/lib64/libX11.so
/home//xbuild/out/lib64/libxcb.so
/usr/lib64/libXdmcp.so -ldl
/home//xbuild/out/lib64/libXfont.so
/usr/lib64/libfreetype.so
/home//xbuild/out/lib64/libfontenc.so
-lz
/home//xbuild/out/lib64/libXau.so
/home//xbuild/out/lib64/libpixman-1.so
/home//xbuild/out/lib64/libXdmcp.so -lm -lrt -Wl,-rpath
-Wl,/home//xbuild/out/lib64 -Wl,-rpath
-Wl,/home//xbuild/out/lib64
   
/home//xbuild/out/lib64/libXi.so: undefined reference to
`XESetWireToEventCookie'
   
/home//xbuild/out/lib64/libXi.so: undefined reference to
`XESetCopyEventCookie'
What appears to be happening, I think, is that it is getting
libraries
like
libXrender and so on from /usr/lib64 instead of my build
directory.
 I'm
not
sure why libtool is doing this.  I have my PKG_CONFIG_PATH set to
my
local
build package config path (/home//xbuild/out/lib64/pkgconfig)
and
LD_LIBRARY_PATH is also set to that (modulo the pkgconfig part).
 I
had
also
built the whole get up without using LD_LIBRARY_PATH.  Same
results.
 The
only two modules that have this problem are pixman and xserver.
 Pixman
I
worked around by passing --disable-gtk to ./configure, since that
was
the
part of the build that was failing.  For xserver, it appears to be
dmx
that's failing.
  
   If I had to guess, the /usr/lib64 is getting hardcoded into one of
   the
   .la libtool archives installed in /home. Can you do grep /usr/lib64
   /home//xbuild/out/lib64/*.la? Maybe there's a problem with
   module
   ordering in xorg.modules. Not sure if that's what's causing the
   reference errors, though.
  
   --
   Dan
  
   I actually did grep for /usr/lib64 in my ~/xbuild (where the source
   and
   output trees live) and removed all references in the libtool archives
   (and
   even in libtool itself!).  It didn't make a difference.
 
  Next time can you record what those references were? That would help
  solve this problem.
 
  They are now attached.  I stripped out some obvious irrelevant lines
  (like
  /usr/lib64/dbus*).  It's down to 254 lines, which hopefully shouldn't be
  too
  much to handle.
  I was not where I could go back to my Linux

Re: Missing symbol error when building X.org from git

[Dan Nicholson]

On Thu, Mar 18, 2010 at 10:54 AM, Joel Feiner jafei...@gmail.com wrote:
 The error that comes up is this:
 libtool: link: gcc -DHAVE_DMX_CONFIG_H -DHAVE_DIX_CONFIG_H -Wall
 -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes
 -Wmissing-declarations -Wnested-externs -fno-strict-aliasing
 -Wbad-function-cast -Wformat=2 -Wold-style-definition
 -Wdeclaration-after-statement -D_BSD_SOURCE -DHAS_FCHOWN
 -DHAS_STICKY_DIR_BIT -I/home//xbuild/out/include/pixman-1
 -I/usr/include/freetype2 -I../../include -I../../include -I../../Xext
 -I../../composite -I../../damageext -I../../xfixes -I../../Xi -I../../mi
 -I../../miext/shadow -I../../miext/damage -I../../render -I../../randr
 -I../../fb -fvisibility=hidden -I../../hw/xfree86/dixmods/extmod
 -I/home//xbuild/out/include/libdrm -I/usr/include/freetype2 -O2
 -mtune=native -march=native -pipe -fomit-frame-pointer -rdynamic -o Xdmx
 dmx.o dmxcb.o dmxcmap.o dmxcursor.o dmxdpms.o dmxextension.o dmxfont.o
 dmxgc.o dmxgcops.o dmxinit.o dmxinput.o dmxlog.o dmxpict.o dmxpixmap.o
 dmxprop.o dmxscrinit.o dmxshadow.o dmxstat.o dmxsync.o dmxvisual.o
 dmxwindow.o miinitext.o fbcmap_mi.o panoramiX.o dmx_glxvisuals.o
  -L/home//xbuild/out/lib64 ../../fb/.libs/libfb.a ../../mi/.libs/libmi.a
 ../../render/.libs/librender.a ../../Xi/.libs/libXi.a
 ../../xkb/.libs/libxkb.a ../../xkb/.libs/libxkbstubs.a
 ../../miext/shadow/.libs/libshadow.a ../../miext/damage/.libs/libdamage.a
 ../../Xext/.libs/libXext.a ../../dix/.libs/libmain.a
 ../../dix/.libs/libdix.a ../../config/.libs/libconfig.a /usr/lib64/libhal.so
 /usr/lib64/libdbus-1.so ../../os/.libs/libos.a /usr/lib64/libgcrypt.so
 -L/usr/lib64 /usr/lib64/libgpg-error.so ../../xfixes/.libs/libxfixes.a
 glxProxy/libglxproxy.a input/libdmxinput.a config/libdmxconfig.a
 /home//xbuild/out/lib64/libXmuu.so /usr/lib64/libXrender.so
 /usr/lib64/libX11.so /usr/lib64/libxcb.so /usr/lib64/libXau.so
 /home//xbuild/out/lib64/libXfixes.so
 /home//xbuild/out/lib64/libXi.so /home//xbuild/out/lib64/libXext.so
 /home//xbuild/out/lib64/libX11.so /home//xbuild/out/lib64/libxcb.so
 /usr/lib64/libXdmcp.so -ldl /home//xbuild/out/lib64/libXfont.so
 /usr/lib64/libfreetype.so /home//xbuild/out/lib64/libfontenc.so -lz
 /home//xbuild/out/lib64/libXau.so
 /home//xbuild/out/lib64/libpixman-1.so
 /home//xbuild/out/lib64/libXdmcp.so -lm -lrt -Wl,-rpath
 -Wl,/home//xbuild/out/lib64 -Wl,-rpath -Wl,/home//xbuild/out/lib64

 /home//xbuild/out/lib64/libXi.so: undefined reference to
 `XESetWireToEventCookie'

 /home//xbuild/out/lib64/libXi.so: undefined reference to
 `XESetCopyEventCookie'
 What appears to be happening, I think, is that it is getting libraries like
 libXrender and so on from /usr/lib64 instead of my build directory.  I'm not
 sure why libtool is doing this.  I have my PKG_CONFIG_PATH set to my local
 build package config path (/home//xbuild/out/lib64/pkgconfig) and
 LD_LIBRARY_PATH is also set to that (modulo the pkgconfig part).  I had also
 built the whole get up without using LD_LIBRARY_PATH.  Same results.  The
 only two modules that have this problem are pixman and xserver.  Pixman I
 worked around by passing --disable-gtk to ./configure, since that was the
 part of the build that was failing.  For xserver, it appears to be dmx
 that's failing.

If I had to guess, the /usr/lib64 is getting hardcoded into one of the
.la libtool archives installed in /home. Can you do grep /usr/lib64
/home//xbuild/out/lib64/*.la? Maybe there's a problem with module
ordering in xorg.modules. Not sure if that's what's causing the
reference errors, though.

--
Dan
___
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg

Re: Missing symbol error when building X.org from git

[Dan Nicholson]

On Thu, Mar 18, 2010 at 12:41 PM, Joel Feiner jafei...@gmail.com wrote:
 On Thu, Mar 18, 2010 at 3:32 PM, Dan Nicholson dbn.li...@gmail.com wrote:

 On Thu, Mar 18, 2010 at 10:54 AM, Joel Feiner jafei...@gmail.com wrote:
  The error that comes up is this:
  libtool: link: gcc -DHAVE_DMX_CONFIG_H -DHAVE_DIX_CONFIG_H -Wall
  -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes
  -Wmissing-declarations -Wnested-externs -fno-strict-aliasing
  -Wbad-function-cast -Wformat=2 -Wold-style-definition
  -Wdeclaration-after-statement -D_BSD_SOURCE -DHAS_FCHOWN
  -DHAS_STICKY_DIR_BIT -I/home//xbuild/out/include/pixman-1
  -I/usr/include/freetype2 -I../../include -I../../include -I../../Xext
  -I../../composite -I../../damageext -I../../xfixes -I../../Xi -I../../mi
  -I../../miext/shadow -I../../miext/damage -I../../render -I../../randr
  -I../../fb -fvisibility=hidden -I../../hw/xfree86/dixmods/extmod
  -I/home//xbuild/out/include/libdrm -I/usr/include/freetype2 -O2
  -mtune=native -march=native -pipe -fomit-frame-pointer -rdynamic -o Xdmx
  dmx.o dmxcb.o dmxcmap.o dmxcursor.o dmxdpms.o dmxextension.o dmxfont.o
  dmxgc.o dmxgcops.o dmxinit.o dmxinput.o dmxlog.o dmxpict.o dmxpixmap.o
  dmxprop.o dmxscrinit.o dmxshadow.o dmxstat.o dmxsync.o dmxvisual.o
  dmxwindow.o miinitext.o fbcmap_mi.o panoramiX.o dmx_glxvisuals.o
   -L/home//xbuild/out/lib64 ../../fb/.libs/libfb.a
  ../../mi/.libs/libmi.a
  ../../render/.libs/librender.a ../../Xi/.libs/libXi.a
  ../../xkb/.libs/libxkb.a ../../xkb/.libs/libxkbstubs.a
  ../../miext/shadow/.libs/libshadow.a
  ../../miext/damage/.libs/libdamage.a
  ../../Xext/.libs/libXext.a ../../dix/.libs/libmain.a
  ../../dix/.libs/libdix.a ../../config/.libs/libconfig.a
  /usr/lib64/libhal.so
  /usr/lib64/libdbus-1.so ../../os/.libs/libos.a /usr/lib64/libgcrypt.so
  -L/usr/lib64 /usr/lib64/libgpg-error.so ../../xfixes/.libs/libxfixes.a
  glxProxy/libglxproxy.a input/libdmxinput.a config/libdmxconfig.a
  /home//xbuild/out/lib64/libXmuu.so /usr/lib64/libXrender.so
  /usr/lib64/libX11.so /usr/lib64/libxcb.so /usr/lib64/libXau.so
  /home//xbuild/out/lib64/libXfixes.so
  /home//xbuild/out/lib64/libXi.so
  /home//xbuild/out/lib64/libXext.so
  /home//xbuild/out/lib64/libX11.so
  /home//xbuild/out/lib64/libxcb.so
  /usr/lib64/libXdmcp.so -ldl /home//xbuild/out/lib64/libXfont.so
  /usr/lib64/libfreetype.so /home//xbuild/out/lib64/libfontenc.so -lz
  /home//xbuild/out/lib64/libXau.so
  /home//xbuild/out/lib64/libpixman-1.so
  /home//xbuild/out/lib64/libXdmcp.so -lm -lrt -Wl,-rpath
  -Wl,/home//xbuild/out/lib64 -Wl,-rpath
  -Wl,/home//xbuild/out/lib64
 
  /home//xbuild/out/lib64/libXi.so: undefined reference to
  `XESetWireToEventCookie'
 
  /home//xbuild/out/lib64/libXi.so: undefined reference to
  `XESetCopyEventCookie'
  What appears to be happening, I think, is that it is getting libraries
  like
  libXrender and so on from /usr/lib64 instead of my build directory.  I'm
  not
  sure why libtool is doing this.  I have my PKG_CONFIG_PATH set to my
  local
  build package config path (/home//xbuild/out/lib64/pkgconfig) and
  LD_LIBRARY_PATH is also set to that (modulo the pkgconfig part).  I had
  also
  built the whole get up without using LD_LIBRARY_PATH.  Same results.
   The
  only two modules that have this problem are pixman and xserver.  Pixman
  I
  worked around by passing --disable-gtk to ./configure, since that was
  the
  part of the build that was failing.  For xserver, it appears to be dmx
  that's failing.

 If I had to guess, the /usr/lib64 is getting hardcoded into one of the
 .la libtool archives installed in /home. Can you do grep /usr/lib64
 /home//xbuild/out/lib64/*.la? Maybe there's a problem with module
 ordering in xorg.modules. Not sure if that's what's causing the
 reference errors, though.

 --
 Dan

 I actually did grep for /usr/lib64 in my ~/xbuild (where the source and
 output trees live) and removed all references in the libtool archives (and
 even in libtool itself!).  It didn't make a difference.

Next time can you record what those references were? That would help
solve this problem.

 Somehow libtool
 found those libraries again.  Note that it *has* found some of the libraries
 in the right place and that's the most confusing part.  I'm not on Linux
 right now, so I can't try diddling with xorg.modules, but I'll try that
 again later this evening or tomorrow.

Well, you would need to clean up in the xserver tree too since now all
the .la files in the tree contain the references to the unwanted
libraries.

 Does X.org require a specific version of libtool?  Perhaps the one I have is
 incorrect or has some bug that interacts badly with X.org builds?  Again, I
 can't check the version right now.

I don't think it's libtool that's causing the problem. It's doing what
it's always done (for better or worse). I suspect the problem is that
there is a module being built out of order that's picking

Re: X doesn't start in minilinux

[Dan Nicholson]

On Thu, Mar 4, 2010 at 12:52 PM, Jay Cotton jay.cot...@sun.com wrote:
 On 03/04/10 11:28, GreenFlash wrote:

 thx, that somebody helps me. Here's the device-Section from my xorg.conf:

 Section Device
         Identifier      VIA
         Driver          vesa
         BusID           PCI:0:2:0
 EndSection

 And the corresponding line from lspci:

 00:02.0 VGA compatible controller: InnoTek Systemberatung GmbH
 VirtualBox Graphics Adapter

 I also just realised, that there are some version differences in the
 xserver and the vesa module. The module is compiled for version 1.6.3,
 but the server has version 1.6.4.
 Might this cause the problem?


 YES.   ABI is important to Xorg now.

Xorg does usually maintain ABI through a minor release series. So, a
1.6.x driver should work with a 1.6.y server without recompiling.

--
Dan
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: Boot resolution

[Dan Nicholson]

On Wed, Mar 3, 2010 at 12:33 AM, Michael auslands...@gmx.de wrote:
 O.K. this time I found the right kernel option. It is (simply):

 video=800x600

 Then it works.

 Cheers

 Michael

 P.S.: Now I need to find out how to make boot messages disappear which are
 visible for about two seconds between splashy stopping and xserver
 starting...

Boot with quiet?

--
Dan
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: cosmetic udev glitches

[Dan Nicholson]

On Wed, Mar 3, 2010 at 4:00 PM, Thomas Jaeger thjae...@gmail.com wrote:
 The attribute 'name' might not exist (as in the case of serial wacom
 devices) and it's impossible to set it in an udev rule, I believe, so we
 should at least fall back to the NAME property if the attribute is not
 available.

Not for the parent, either? Does hal give you anything for
info.product/input.product?

--
Dan
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: cosmetic udev glitches

[Dan Nicholson]

On Tue, Mar 2, 2010 at 9:28 AM, Julien Cristau jcris...@debian.org wrote:
 On Tue, Mar  2, 2010 at 17:57:04 +0100, Simon Thum wrote:

 Hi all,

 I just upgraded my X to use udev. It generally went fine, but  I noticed
 two minor issues:

 At first, the device names have quotation marks. As in

 xinput list
 ...
 ⎜     ImExPS/2 Logitech Wheel Mouse           id=7    [slave  pointer
  (2)]

 I looked up the source, but found nothing obvious. Is this expected
 behavior?

 Yes, the device names we get from udev have quotations marks.  I don't
 know why, and I didn't feel like mangling them.

It seems to come straight from the kernel (drivers/input/input.c),
which adds the quotes around the value in NAME to the uevent. Maybe we
should ask them not to do that. Looks like this was changed back in
2005, commit a7fadbe10ccf430e7a8add8b45c561d864087343.

However, I think we should try to be compatible with info.product from
hal. This would require some amount of mangling. What hal does is:

1. Get the name directly from the sysfs name file (no quotes there)
2. Strip trailing whitespace

 Second, udev seems to add my mouse (and others) twice, resulting in some
 log spam. Excerpt:

 [  5571.537] (II) config/udev: Adding input device ImExPS/2 Logitech
 Wheel Mouse (/dev/input/event3)
 (...)
 [  5571.538] (II) XINPUT: Adding extended input device ImExPS/2
 Logitech Wheel Mouse (type: MOUSE)
 [  5571.538] (II) ImExPS/2 Logitech Wheel Mouse: initialized for
 relative axes.
 [  5571.538] (II) config/udev: Adding input device ImExPS/2 Logitech
 Wheel Mouse (/dev/input/mouse0)
 [  5571.538] (**) ImExPS/2 Logitech Wheel Mouse: Applying InputClass
 evdev catchall
 [  5571.538] (**) ImExPS/2 Logitech Wheel Mouse: always reports core
 events
 [  5571.538] (**) ImExPS/2 Logitech Wheel Mouse: Device:
 /dev/input/mouse0
 [  5571.539] (EE) ioctl EVIOCGNAME failed: Inappropriate ioctl for device
 [  5571.539] (II) UnloadModule: evdev
 [  5571.539] (EE) PreInit returned NULL for ImExPS/2 Logitech Wheel
 Mouse


 Things work fine here, I just wanted to make sure whether my
 configuration is broken or these are known issues.

 This is also expected at the moment.  The enumeration of devices gives
 us /dev/input/event* (which evdev can handle), and
 /dev/input/{mouse,kbd}* (which it doesn't).  This results in a couple
 error messages for the latter.  It should be possible to tone those down
 so users don't get scared…

The other thing hal does here is ignore all devices except those where
the sysfs path ends in event%d. Maybe we should do the same.

--
Dan
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: cosmetic udev glitches

[Dan Nicholson]

On Tue, Mar 02, 2010 at 05:57:04PM +0100, Simon Thum wrote:
 Hi all,
 
 I just upgraded my X to use udev. It generally went fine, but  I noticed
 two minor issues:
 
 At first, the device names have quotation marks. As in
 
 xinput list
 ...
 ⎜ ImExPS/2 Logitech Wheel Mouse   id=7[slave  pointer
  (2)]
 
 I looked up the source, but found nothing obvious. Is this expected
 behavior?
 
 Second, udev seems to add my mouse (and others) twice, resulting in some
 log spam. Excerpt:
 
 [  5571.537] (II) config/udev: Adding input device ImExPS/2 Logitech
 Wheel Mouse (/dev/input/event3)
 (...)
 [  5571.538] (II) XINPUT: Adding extended input device ImExPS/2
 Logitech Wheel Mouse (type: MOUSE)
 [  5571.538] (II) ImExPS/2 Logitech Wheel Mouse: initialized for
 relative axes.
 [  5571.538] (II) config/udev: Adding input device ImExPS/2 Logitech
 Wheel Mouse (/dev/input/mouse0)
 [  5571.538] (**) ImExPS/2 Logitech Wheel Mouse: Applying InputClass
 evdev catchall
 [  5571.538] (**) ImExPS/2 Logitech Wheel Mouse: always reports core
 events
 [  5571.538] (**) ImExPS/2 Logitech Wheel Mouse: Device:
 /dev/input/mouse0
 [  5571.539] (EE) ioctl EVIOCGNAME failed: Inappropriate ioctl for device
 [  5571.539] (II) UnloadModule: evdev
 [  5571.539] (EE) PreInit returned NULL for ImExPS/2 Logitech Wheel
 Mouse
 
 
 Things work fine here, I just wanted to make sure whether my
 configuration is broken or these are known issues.
 
 In case it helps, I did:
 udevadm info --attribute-walk --name /dev/input/mouse0
 
 Udevadm info starts with the device specified by the devpath and then
 walks up the chain of parent devices. It prints for every device
 found, all possible attributes in the udev rules key format.
 A rule to match, can be composed by the attributes of the device
 and the attributes from one single parent device.
 
   looking at device '/devices/platform/i8042/serio1/input/input3/mouse0':
 KERNEL==mouse0
 SUBSYSTEM==input
 DRIVER==
 
   looking at parent device '/devices/platform/i8042/serio1/input/input3':
 KERNELS==input3
 SUBSYSTEMS==input
 DRIVERS==
 ATTRS{name}==ImExPS/2 Logitech Wheel Mouse
 ATTRS{phys}==isa0060/serio1/input0
 ATTRS{uniq}==

Can you try the patch below that uses the name attribute instead of the
value from the uevent? I ran it through a little test app, but not in X.

Dan

From c01a4e6dce7196a60b5247dde78054b27e004494 Mon Sep 17 00:00:00 2001
From: Dan Nicholson dbn.li...@gmail.com
Date: Tue, 2 Mar 2010 14:42:22 -0800
Subject: [PATCH] config/udev: Get product name from attribute instead of uevent

The input device product name in the kernel uevent has embedded quotes
that aren't expected here. Use the sysfs name attribute instead, which
does not suffer this problem.

Signed-off-by: Dan Nicholson dbn.li...@gmail.com
---
 config/udev.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/config/udev.c b/config/udev.c
index 69257e9..54306ef 100644
--- a/config/udev.c
+++ b/config/udev.c
@@ -74,7 +74,7 @@ device_added(struct udev_device *udev_device)
 
 parent = udev_device_get_parent(udev_device);
 if (parent)
-name = udev_device_get_property_value(parent, NAME);
+name = udev_device_get_sysattr_value(parent, name);
 if (!name)
 name = (unnamed);
 else
-- 
1.6.6.1
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: cosmetic udev glitches

[Dan Nicholson]

On Tue, Mar 2, 2010 at 4:16 PM, Peter Hutterer peter.hutte...@who-t.net wrote:
 On Tue, Mar 02, 2010 at 02:47:22PM -0800, Dan Nicholson wrote:
 Can you try the patch below that uses the name attribute instead of the
 value from the uevent? I ran it through a little test app, but not in X.

 From c01a4e6dce7196a60b5247dde78054b27e004494 Mon Sep 17 00:00:00 2001
 From: Dan Nicholson dbn.li...@gmail.com
 Date: Tue, 2 Mar 2010 14:42:22 -0800
 Subject: [PATCH] config/udev: Get product name from attribute instead of 
 uevent

 The input device product name in the kernel uevent has embedded quotes
 that aren't expected here. Use the sysfs name attribute instead, which
 does not suffer this problem.

 Signed-off-by: Dan Nicholson dbn.li...@gmail.com
 ---
  config/udev.c |    2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)

 diff --git a/config/udev.c b/config/udev.c
 index 69257e9..54306ef 100644
 --- a/config/udev.c
 +++ b/config/udev.c
 @@ -74,7 +74,7 @@ device_added(struct udev_device *udev_device)

      parent = udev_device_get_parent(udev_device);
      if (parent)
 -        name = udev_device_get_property_value(parent, NAME);
 +        name = udev_device_get_sysattr_value(parent, name);
      if (!name)
          name = (unnamed);
      else
 --
 1.6.6.1

 Reviewed-by: Peter Hutterer peter.hutte...@who-t.net

 tested too.

Is this on rawhide with udev-151? When I tried it against the udev on
f12, it was replacing the spaces in the name with underscores. I can't
figure out why, but when I ran it against a vanilla udev 145 or git,
it worked fine.

--
Dan
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: cosmetic udev glitches

[Dan Nicholson]

On Wed, Mar 03, 2010 at 10:40:16AM +1000, Peter Hutterer wrote:
 On Tue, Mar 02, 2010 at 04:29:41PM -0800, Dan Nicholson wrote:
  On Tue, Mar 2, 2010 at 4:16 PM, Peter Hutterer peter.hutte...@who-t.net 
  wrote:
   On Tue, Mar 02, 2010 at 02:47:22PM -0800, Dan Nicholson wrote:
   Can you try the patch below that uses the name attribute instead of the
   value from the uevent? I ran it through a little test app, but not in X.
  
   From c01a4e6dce7196a60b5247dde78054b27e004494 Mon Sep 17 00:00:00 2001
   From: Dan Nicholson dbn.li...@gmail.com
   Date: Tue, 2 Mar 2010 14:42:22 -0800
   Subject: [PATCH] config/udev: Get product name from attribute instead of 
   uevent
  
   The input device product name in the kernel uevent has embedded quotes
   that aren't expected here. Use the sysfs name attribute instead, which
   does not suffer this problem.
  
   Signed-off-by: Dan Nicholson dbn.li...@gmail.com
   ---
    config/udev.c |    2 +-
    1 files changed, 1 insertions(+), 1 deletions(-)
  
   diff --git a/config/udev.c b/config/udev.c
   index 69257e9..54306ef 100644
   --- a/config/udev.c
   +++ b/config/udev.c
   @@ -74,7 +74,7 @@ device_added(struct udev_device *udev_device)
  
        parent = udev_device_get_parent(udev_device);
        if (parent)
   -        name = udev_device_get_property_value(parent, NAME);
   +        name = udev_device_get_sysattr_value(parent, name);
        if (!name)
            name = (unnamed);
        else
   --
   1.6.6.1
  
   Reviewed-by: Peter Hutterer peter.hutte...@who-t.net
  
   tested too.
  
  Is this on rawhide with udev-151? When I tried it against the udev on
  f12, it was replacing the spaces in the name with underscores. I can't
  figure out why, but when I ran it against a vanilla udev 145 or git,
  it worked fine.
 
 This was on F12 (X server from git) and I don't see the underscore issue you
 mentioned. Updates-testing from yesterday.
 Not quite sure where that comes from tbh.

Never mind. I don't know what I doing, but it's working now. Here's my
little test app for reference. You have to pass it the sysfs device path.

--
Dan

#include stdlib.h
#include stdio.h
#include string.h

#define LIBUDEV_I_KNOW_THE_API_IS_SUBJECT_TO_CHANGE 1
#include libudev.h

int main(int argc, char *argv[])
{
struct udev *udev;
struct udev_device *device, *parent;
const char *path, *name;

if (argc  2) {
fprintf(stderr, No device path specified\n);
exit(EXIT_FAILURE);
}
path = argv[1];

udev = udev_new();
device = udev_device_new_from_syspath(udev, path);
if (!device) {
fprintf(stderr, Device not found from path \%s\\n, path);
exit(EXIT_FAILURE);
}
parent = udev_device_get_parent(device);
if (!parent)
parent = device;
name = udev_device_get_sysattr_value(parent, name);
printf(%s: \%s\\n, path, name);

udev_device_unref(device);
udev_unref(udev);

return 0;
}
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: Problems Compiling from Git

[Dan Nicholson]

On Thu, Feb 18, 2010 at 2:36 PM, Mike Lothian m...@fireburn.co.uk wrote:
 I'm experiencing 3 issues at the moment

 xorg-server master isn't compiling I get the error:

 ../doltcompile x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I.
 -I../include -I../hw/xfree86/os-support -I../hw/xfree86/os-support/bus
 -I../hw/xfree86/common -I../hw/xfree86/dri -I../mi
 -I../hw/xfree86/dri2   -DHAVE_DIX_CONFIG_H -Wall -Wpointer-arith
 -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations
 -Wnested-externs -fno-strict-aliasing -Wbad-function-cast -Wformat=2
 -Wold-style-definition -Wdeclaration-after-statement  -D_BSD_SOURCE
 -DHAS_FCHOWN -DHAS_STICKY_DIR_BIT -I/usr/include/freetype2
 -I/usr/include/pixman-1   -I../include -I../include -I../Xext
 -I../composite -I../damageext -I../xfixes -I../Xi -I../mi
 -I../miext/shadow  -I../miext/damage -I../render -I../randr -I../fb
 -fvisibility=hidden -I/usr/include/drm -I/usr/include/drm
 -I/usr/include/drm -I/usr/include/X11/dri -DXFree86Server
 -DGLX_USE_TLS -DPTHREADS -D__GLX_ALIGN64 -march=native -O2 -pipe -w
 -MT glxdri2.lo -MD -MP -MF .deps/glxdri2.Tpo -c -o glxdri2.lo
 glxdri2.c
 glxdri2.c: In function '__glXDRIdrawableSwapBuffers':
 glxdri2.c:221: error: '__DRI2flushExtension' has no member named
 'flushInvalidate'

 mesa wont compile. I have no idea what's happening

 gmake[5]: Entering directory
 `/var/tmp/portage/media-libs/mesa-/work/Mesa-/src/mesa/drivers/dri/swrast'
 running /usr/bin/makedepend
 gmake[5]: Leaving directory
 `/var/tmp/portage/media-libs/mesa-/work/Mesa-/src/mesa/drivers/dri/swrast'
 gmake[5]: Entering directory
 `/var/tmp/portage/media-libs/mesa-/work/Mesa-/src/mesa/drivers/dri/swrast'
 gmake[6]: Entering directory
 `/var/tmp/portage/media-libs/mesa-/work/Mesa-/src/mesa/drivers/dri/swrast'
 x86_64-pc-linux-gnu-gcc -c -I.
 -I../../../../../src/mesa/drivers/dri/common -Iserver
 -I../../../../../include -I../../../../../src/mesa
 -I../../../../../src/egl/main -I../../../../../src/egl/drivers/dri
 -I/usr/include/drm    -march=native -O2 -pipe -w -ffast-math -Wall
 -Wmissing-prototypes -std=c99 -ffast-math -fvisibility=hidden
 -fno-strict-aliasing  -fPIC   -D_GNU_SOURCE -DPTHREADS
 -DHAVE_POSIX_MEMALIGN -DUSE_XCB -DGLX_USE_TLS -DPTHREADS
 -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING
 -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS  ../common/utils.c -o
 ../common/utils.o
 x86_64-pc-linux-gnu-gcc -c -I.
 -I../../../../../src/mesa/drivers/dri/common -Iserver
 -I../../../../../include -I../../../../../src/mesa
 -I../../../../../src/egl/main -I../../../../../src/egl/drivers/dri
 -I/usr/include/drm    -march=native -O2 -pipe -w -ffast-math -Wall
 -Wmissing-prototypes -std=c99 -ffast-math -fvisibility=hidden
 -fno-strict-aliasing  -fPIC   -D_GNU_SOURCE -DPTHREADS
 -DHAVE_POSIX_MEMALIGN -DUSE_XCB -DGLX_USE_TLS -DPTHREADS
 -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING
 -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS  swrast.c -o swrast.o
 x86_64-pc-linux-gnu-gcc -c -I.
 -I../../../../../src/mesa/drivers/dri/common -Iserver
 -I../../../../../include -I../../../../../src/mesa
 -I../../../../../src/egl/main -I../../../../../src/egl/drivers/dri
 -I/usr/include/drm    -march=native -O2 -pipe -w -ffast-math -Wall
 -Wmissing-prototypes -std=c99 -ffast-math -fvisibility=hidden
 -fno-strict-aliasing  -fPIC   -D_GNU_SOURCE -DPTHREADS
 -DHAVE_POSIX_MEMALIGN -DUSE_XCB -DGLX_USE_TLS -DPTHREADS
 -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING
 -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS  swrast_span.c -o swrast_span.o
 /bin/sh ../../../../../bin/mklib -o swrast_dri.so -noprefix -linker
 'x86_64-pc-linux-gnu-gcc' -ldflags '-Wl,-O1 -Wl,--hash-style=gnu
 -Wl,--as-needed' \
                ../../common/driverfuncs.o ../common/utils.o swrast.o
 swrast_span.o   ../../../../../src/mesa/libmesa.a   \
                  -ldrm   -lexpat -lm -lpthread -ldl
 mklib: Making Linux shared library:  swrast_dri.so
 gmake[6]: *** [swrast_dri.so] Error 1
 gmake[6]: Leaving directory
 `/var/tmp/portage/media-libs/mesa-/work/Mesa-/src/mesa/drivers/dri/swrast'
 gmake[5]: *** [lib] Error 2
 gmake[5]: Leaving directory
 `/var/tmp/portage/media-libs/mesa-/work/Mesa-/src/mesa/drivers/dri/swrast'
 gmake[4]: *** [subdirs] Error 1
 gmake[4]: Leaving directory
 `/var/tmp/portage/media-libs/mesa-/work/Mesa-/src/mesa/drivers/dri'
 gmake[3]: *** [default] Error 1

For this one, you should revert commit
d6f55492af3cb82b0113fe6beac0f3494b6e2956. trap and exit on ERR
shouldn't be used blindly since it's entirely possible there are
commands that safely fail in mklib. Not to mention that it's not
portable.

--
Dan
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: Problems Compiling from Git

[Dan Nicholson]

On Thu, Feb 18, 2010 at 2:52 PM, Mike Lothian m...@fireburn.co.uk wrote:
 On 18 February 2010 22:46, Dan Nicholson dbn.li...@gmail.com wrote:
 On Thu, Feb 18, 2010 at 2:36 PM, Mike Lothian m...@fireburn.co.uk wrote:
 I'm experiencing 3 issues at the moment

 xorg-server master isn't compiling I get the error:

 ../doltcompile x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I.
 -I../include -I../hw/xfree86/os-support -I../hw/xfree86/os-support/bus
 -I../hw/xfree86/common -I../hw/xfree86/dri -I../mi
 -I../hw/xfree86/dri2   -DHAVE_DIX_CONFIG_H -Wall -Wpointer-arith
 -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations
 -Wnested-externs -fno-strict-aliasing -Wbad-function-cast -Wformat=2
 -Wold-style-definition -Wdeclaration-after-statement  -D_BSD_SOURCE
 -DHAS_FCHOWN -DHAS_STICKY_DIR_BIT -I/usr/include/freetype2
 -I/usr/include/pixman-1   -I../include -I../include -I../Xext
 -I../composite -I../damageext -I../xfixes -I../Xi -I../mi
 -I../miext/shadow  -I../miext/damage -I../render -I../randr -I../fb
 -fvisibility=hidden -I/usr/include/drm -I/usr/include/drm
 -I/usr/include/drm -I/usr/include/X11/dri -DXFree86Server
 -DGLX_USE_TLS -DPTHREADS -D__GLX_ALIGN64 -march=native -O2 -pipe -w
 -MT glxdri2.lo -MD -MP -MF .deps/glxdri2.Tpo -c -o glxdri2.lo
 glxdri2.c
 glxdri2.c: In function '__glXDRIdrawableSwapBuffers':
 glxdri2.c:221: error: '__DRI2flushExtension' has no member named
 'flushInvalidate'

 mesa wont compile. I have no idea what's happening

 gmake[5]: Entering directory
 `/var/tmp/portage/media-libs/mesa-/work/Mesa-/src/mesa/drivers/dri/swrast'
 running /usr/bin/makedepend
 gmake[5]: Leaving directory
 `/var/tmp/portage/media-libs/mesa-/work/Mesa-/src/mesa/drivers/dri/swrast'
 gmake[5]: Entering directory
 `/var/tmp/portage/media-libs/mesa-/work/Mesa-/src/mesa/drivers/dri/swrast'
 gmake[6]: Entering directory
 `/var/tmp/portage/media-libs/mesa-/work/Mesa-/src/mesa/drivers/dri/swrast'
 x86_64-pc-linux-gnu-gcc -c -I.
 -I../../../../../src/mesa/drivers/dri/common -Iserver
 -I../../../../../include -I../../../../../src/mesa
 -I../../../../../src/egl/main -I../../../../../src/egl/drivers/dri
 -I/usr/include/drm    -march=native -O2 -pipe -w -ffast-math -Wall
 -Wmissing-prototypes -std=c99 -ffast-math -fvisibility=hidden
 -fno-strict-aliasing  -fPIC   -D_GNU_SOURCE -DPTHREADS
 -DHAVE_POSIX_MEMALIGN -DUSE_XCB -DGLX_USE_TLS -DPTHREADS
 -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING
 -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS  ../common/utils.c -o
 ../common/utils.o
 x86_64-pc-linux-gnu-gcc -c -I.
 -I../../../../../src/mesa/drivers/dri/common -Iserver
 -I../../../../../include -I../../../../../src/mesa
 -I../../../../../src/egl/main -I../../../../../src/egl/drivers/dri
 -I/usr/include/drm    -march=native -O2 -pipe -w -ffast-math -Wall
 -Wmissing-prototypes -std=c99 -ffast-math -fvisibility=hidden
 -fno-strict-aliasing  -fPIC   -D_GNU_SOURCE -DPTHREADS
 -DHAVE_POSIX_MEMALIGN -DUSE_XCB -DGLX_USE_TLS -DPTHREADS
 -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING
 -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS  swrast.c -o swrast.o
 x86_64-pc-linux-gnu-gcc -c -I.
 -I../../../../../src/mesa/drivers/dri/common -Iserver
 -I../../../../../include -I../../../../../src/mesa
 -I../../../../../src/egl/main -I../../../../../src/egl/drivers/dri
 -I/usr/include/drm    -march=native -O2 -pipe -w -ffast-math -Wall
 -Wmissing-prototypes -std=c99 -ffast-math -fvisibility=hidden
 -fno-strict-aliasing  -fPIC   -D_GNU_SOURCE -DPTHREADS
 -DHAVE_POSIX_MEMALIGN -DUSE_XCB -DGLX_USE_TLS -DPTHREADS
 -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING
 -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS  swrast_span.c -o swrast_span.o
 /bin/sh ../../../../../bin/mklib -o swrast_dri.so -noprefix -linker
 'x86_64-pc-linux-gnu-gcc' -ldflags '-Wl,-O1 -Wl,--hash-style=gnu
 -Wl,--as-needed' \
                ../../common/driverfuncs.o ../common/utils.o swrast.o
 swrast_span.o   ../../../../../src/mesa/libmesa.a   \
                  -ldrm   -lexpat -lm -lpthread -ldl
 mklib: Making Linux shared library:  swrast_dri.so
 gmake[6]: *** [swrast_dri.so] Error 1
 gmake[6]: Leaving directory
 `/var/tmp/portage/media-libs/mesa-/work/Mesa-/src/mesa/drivers/dri/swrast'
 gmake[5]: *** [lib] Error 2
 gmake[5]: Leaving directory
 `/var/tmp/portage/media-libs/mesa-/work/Mesa-/src/mesa/drivers/dri/swrast'
 gmake[4]: *** [subdirs] Error 1
 gmake[4]: Leaving directory
 `/var/tmp/portage/media-libs/mesa-/work/Mesa-/src/mesa/drivers/dri'
 gmake[3]: *** [default] Error 1

 For this one, you should revert commit
 d6f55492af3cb82b0113fe6beac0f3494b6e2956. trap and exit on ERR
 shouldn't be used blindly since it's entirely possible there are
 commands that safely fail in mklib. Not to mention that it's not
 portable.

 --
 Dan


 Thanks Dan

 Does any one have access to get this reverted on master?

I just did it. Try again.

--
Dan
___
xorg

Re: [ANNOUNCE] xorg-server 1.7.99.901

[Dan Nicholson]

On Fri, Feb 12, 2010 at 5:57 PM, Stephan Raue mailingli...@openelec.tv wrote:
 Hi all,

 please dont forget to include these 2 patches:

 http://lists.freedesktop.org/archives/xorg/2009-December/048500.html
 http://lists.freedesktop.org/archives/xorg-devel/2010-January/004985.html

I think they're both in:

   Don't use AC_CHECK_FILE for fontpath checks when cross compiling
   xfree86: Handle config files ending without newline

--
Dan
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: modular build, libGL make install fails

[Dan Nicholson]

On Sat, Jan 30, 2010 at 3:17 PM, David Gerard dger...@gmail.com wrote:
 Is this a bug, or just me? This is doing the modular build with jhbuild:

 /home/fun/.local/bin/install-check -d /usr/local/include/GL
 install: cannot change permissions of `/usr/local/include/GL': No such
 file or directory
 make[3]: *** [install-headers] Error 1
 make[3]: Leaving directory `/home/fun/git/mesa/src/mesa'
 make[2]: *** [install] Error 1
 make[2]: Leaving directory `/home/fun/git/mesa/src/mesa'
 make[1]: *** [install] Error 1
 make[1]: Leaving directory `/home/fun/git/mesa/src'
 make: *** [install] Error 1
 *** Error during phase install of libGL: ## Error running make
 install *** [66/168]

 I'm doing a build in my home directory, but it appears to be trying to
 do things to the system. Surely that's not right ...

 What's an appropriate workaround here?

Mesa is trying to install in /usr/local, apparently. I don't know what
jhbuild is doing, but obviously we'd need to see more context.

--
Dan
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: Xorg-1.7.3 XCALIBRATE touchscreen

[Dan Nicholson]

On Fri, Jan 15, 2010 at 9:25 AM, Marco Cavallini koansoftw...@gmail.com wrote:
 Hi,
 I am using an ARM based architecture and I am trying to enable
 touchscreen calibration without success.
 I built Xorg version Xorg-1.7.3 configured with --enable-xcalibrate
 but I didn't get this extension in my Xorg, so when I try to call xtscal
 I get this error:
  # xtscal
  XCALIBRATE extension missing: Success

 I debugged a bit the following packages (xtscal_0.6.3,
 libxcalibrate_git, libxext_1.1.1) and I realized that the problem is
 into Xorg so I wonder how could I enable XCALIBRATE.

 Any help would be greatly appreciated.
 If any functionality is missing I'd like to get a hint about how to
 proceed to implement, debug and test it.

Can you post Xorg.log? Did configure give you any messages about
xcalibrate when you used --enable-xcalibrate?

--
Dan
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: Xorg-1.7.3 XCALIBRATE touchscreen

[Dan Nicholson]

On Fri, Jan 15, 2010 at 11:13 AM, Marco Cavallini
koansoftw...@gmail.com wrote:
 Dan Nicholson ha scritto, Il 15/01/2010 18:38:
 On Fri, Jan 15, 2010 at 9:25 AM, Marco Cavallini koansoftw...@gmail.com 
 wrote:
 Hi,
 I am using an ARM based architecture and I am trying to enable
 touchscreen calibration without success.
 I built Xorg version Xorg-1.7.3 configured with --enable-xcalibrate
 but I didn't get this extension in my Xorg, so when I try to call xtscal
 I get this error:
  # xtscal
  XCALIBRATE extension missing: Success

 I debugged a bit the following packages (xtscal_0.6.3,
 libxcalibrate_git, libxext_1.1.1) and I realized that the problem is
 into Xorg so I wonder how could I enable XCALIBRATE.

 Any help would be greatly appreciated.
 If any functionality is missing I'd like to get a hint about how to
 proceed to implement, debug and test it.

 Can you post Xorg.log? Did configure give you any messages about
 xcalibrate when you used --enable-xcalibrate?

 --

 Dan,
 thank you for answering.
 Now I'm at home and I haven't access to the target machine, but I can
 pastebin you the config.log : http://pastebin.com/m4ecd3f48

The config.log says that you don't have the XCALIBRATE extension built
into the server.

XCALIBRATE_TRUE='#'

That means the automake conditional to build the xcalibrate sources
will be false. So, you'll have to run configure again and see what it
says about finding the xcalibrate dependencies.

--
Dan
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: Xorg-1.7.3 XCALIBRATE touchscreen

[Dan Nicholson]

On Fri, Jan 15, 2010 at 12:33 PM, Marco Cavallini
koansoftw...@gmail.com wrote:
 Dan Nicholson ha scritto, Il 15/01/2010 19:17:

 The config.log says that you don't have the XCALIBRATE extension built
 into the server.

 XCALIBRATE_TRUE='#'

 That means the automake conditional to build the xcalibrate sources
 will be false. So, you'll have to run configure again and see what it
 says about finding the xcalibrate dependencies.


 Looks like configure.ac wants KDRIVE in order to enable xcalibrate,
 isn't it?

 if test x$XCALIBRATE = xyes  test $KDRIVE = yes; then
   AC_DEFINE(XCALIBRATE, 1, [Build XCalibrate extension])
   REQUIRED_MODULES=$REQUIRED_MODULES $XCALIBRATEPROTO
 else
   XCALIBRATE=no
 fi
 AM_CONDITIONAL(XCALIBRATE, [test x$XCALIBRATE = xyes])

 What do you suggest to do?

Yeah, the xcalibrate extension is only implemented for kdrive. I think
your options are to use kdrive or find another way to calibrate your
touchscreen. I know there are other solutions out there, but I'm not
really familiar with the touchscreen world.

--
Dan
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: [ANNOUNCE] xorg-server 1.7.99.2

[Dan Nicholson]

On Mon, Jan 11, 2010 at 10:40 PM, Peter Hutterer
peter.hutte...@who-t.net wrote:
 On Mon, Jan 11, 2010 at 08:54:59AM +0100, Stephan Raue wrote:
 Hi Peter, Dan,

 do you dont forgot this also to commit before release?

 Dan, this patch doesn't seem to be in master yet. were you waiting for me to
 merge it?

I'd forgotten about it. My development box is offline right now, so if
you could check that it still applies and add your Reviewed-by to the
commit message, that'd be great. Thanks.

--
Dan
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: I don't want my IR handset to act like a keyboard

[Dan Nicholson]

On Tue, Jan 12, 2010 at 2:50 PM, Tony Houghton h...@realh.co.uk wrote:
 On Tue, 12 Jan 2010 13:07:03 -0800
 Paul Bender peben...@san.rr.com wrote:

 My solution to this problem is customized udev scripts. Essentially, if
 the device is a remote, then udev does not set x11_driver. Since
 x11_driver is not set, Xorg ignores the device completely.

 Oh good, that is still possible. Could you tell me how? I couldn't work
 out what to do, or even if there was anything I could do, from the udev
 docs.

It's gone in master (and probably soon from debian/ubuntu). The server
just grabs everything marked with ID_INPUT by udev.

--
Dan
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: Xorg crashes...

[Dan Nicholson]

On Fri, Jan 8, 2010 at 6:01 AM, Ryan Daly d...@ctc.com wrote:
 On 01/07/2010 06:11 PM, Dan Nicholson wrote:

 Not sure this will work, but if it's a symbol resolving problem, you
 can try to get it to crash faster by using LD_BIND_NOW.

 LD_BIND_NOW=1 startx `which xterm`

 X will not start with LD_BIND_NOW set to 1.  It's unable to load
 /usr/lib/xorg/modules/drivers/nv_drv.so.

OK, doesn't seem like that's the issue anyway.

--
Dan
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: Xorg crashes...

[Dan Nicholson]

On Fri, Jan 8, 2010 at 8:19 AM, Dan Nicholson dbn.li...@gmail.com wrote:
 On Fri, Jan 8, 2010 at 7:19 AM, Ryan Daly d...@ctc.com wrote:
 On 01/08/2010 10:11 AM, Tom Cowell wrote:
 I was responding to this remark from Peter Hutterer:

 uhm. SIGTERM is the termination signal. Something's shutting down your
 server.

 If SIGTERM is coming from another process, then the debugger won't
 provide any information about _which_ process. However, a recursive
 strace of startx (and all its children and grandchildren) _might_
 identify the source of the signal. Even if the X Server is killing
 itself with SIGTERM, that would be worth knowing.

 However, if it stays up for days before crashing, strace might
 generate an unacceptable amount of output.

 I gotcha...  I'll try that and post any relevant information.

 FYI, the error in the log on launchpad was a segfault (SIGSEGV), so
 you appear to have two different errors. The segfault (signal 11)
 should be fixable. The mysterious SIGTERM might be tough to handle
 since it could come from anywhere.

Peter, do you have any ideas about this one:

http://launchpadlibrarian.net/37615863/gdb-Xorg.txt

--
Dan
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: Xorg crashes...

[Dan Nicholson]

On Fri, Jan 8, 2010 at 7:19 AM, Ryan Daly d...@ctc.com wrote:
 On 01/08/2010 10:11 AM, Tom Cowell wrote:
 I was responding to this remark from Peter Hutterer:

 uhm. SIGTERM is the termination signal. Something's shutting down your
 server.

 If SIGTERM is coming from another process, then the debugger won't
 provide any information about _which_ process. However, a recursive
 strace of startx (and all its children and grandchildren) _might_
 identify the source of the signal. Even if the X Server is killing
 itself with SIGTERM, that would be worth knowing.

 However, if it stays up for days before crashing, strace might
 generate an unacceptable amount of output.

 I gotcha...  I'll try that and post any relevant information.

FYI, the error in the log on launchpad was a segfault (SIGSEGV), so
you appear to have two different errors. The segfault (signal 11)
should be fixable. The mysterious SIGTERM might be tough to handle
since it could come from anywhere.

--
Dan
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: Xorg crashes...

[Dan Nicholson]

On Thu, Jan 7, 2010 at 11:26 AM, Ryan Daly d...@ctc.com wrote:
 On 01/07/2010 01:25 PM, Justin P. Mattock wrote:
 I know it says these errors aren't fatal to the X server, but could they
 be causing me problems?


 as for xkbcomp doing a quick google
 gave me this:
 http://bugs.gentoo.org/269931

 but still don't see that this is the
 culprit.

 I read through the bug reports...  No one has a fix yet, so I'm not sure
 what I should do with regard to that.  And if you don't think it's
 causing X to quit, then it may not be worth going down that road anyway.

xkbcomp is almost certainly not killing the server. If you run startx
then switch back to the VT you started from, you'll see those errors
are only generated during initialization (unless you plug in another
keyboard later).

If you run startx `which xterm` so that you're just running a
terminal, does the server still exit?

--
Dan
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: Xorg crashes...

[Dan Nicholson]

On Thu, Jan 7, 2010 at 2:45 PM, Ryan Daly d...@ctc.com wrote:
 On 01/07/2010 05:30 PM, Peter Hutterer wrote:
 waiting for X server to shut down  ddxSigGiveUp: Closing log
 /Xorg.out

 I know it says these errors aren't fatal to the X server, but could they
 be causing me problems?

 as for xkbcomp doing a quick google
 gave me this:
 http://bugs.gentoo.org/269931

 but still don't see that this is the
 culprit.

 this is a non-fatal error and doesn't affect anything but the warning to be
 printed out.

 OK.  I won't pursue that, then.  Do you have any suggestions on what my
 next step would be?  Have you picked up anything from the backtrace
 that's attached to the bug report at bugs.launchpad.net?

Not sure this will work, but if it's a symbol resolving problem, you
can try to get it to crash faster by using LD_BIND_NOW.

LD_BIND_NOW=1 startx `which xterm`

--
Dan
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: X11 XTEST Error when starting Xine

[Dan Nicholson]

On Sun, Jan 3, 2010 at 2:04 PM, Jim Duda j...@duda.tzo.com wrote:
 On 01/02/2010 09:45 AM, Benjamin Close wrote:

 I'd suggest you try reinstalling libXi and libX11
 The XTest code has had changes to it caused by the update to the XInput
 layer (libXi) which also may affect libX11.

 Cheers,
       Benjamin

 Thanks for the post.  I tried reinstalling all the libX libraries which
 were installed, using rpm -e --nodeps, then yum install each of the
 libraries.

 I have diffed the libraries between a working machine and all have
 a binary match.  There must be some meta-data file outside the libraries
 which return the results for XKeysymToKeycode ?

Two things affect XKeysymToKeycode:

$includedir/X11/keysymdef.h (built into libX11 as a hash table)
$datadir/X11/XKeysymDB (cached at runtime)

You could try moving XKeysymDB out of the way, or try building you're
own Xlib for testing. Pull xproto (for the newest keysymdef.h) and
libX11 and build them --prefix=$HOME (or somewhere else) making sure
to set PKG_CONFIG_PATH=$HOME/lib/pkgconfig:$HOME/share/pkgconfig so
that the new xproto is picked up. Then run your app with
LD_LIBRARY_PATH=$HOME/lib and see if you still see errors.

--
Dan
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: [news] TWM -- Revised Edition -- Again

[Dan Nicholson]

On Sun, Jan 3, 2010 at 9:45 AM, Eeri Kask eeri.k...@inf.tu-dresden.de wrote:
 Hello TWM users,

 As a followup to

 http://lists.freedesktop.org/archives/xorg/2008-September/039069.html

 may I here present some efforts to improve twm even further a little.

Improvements all sound good, but I'm really curious if you've
requested a freedesktop.org account to develop twm? You certainly have
given twm more love than anyone else over the recent years. In fact,
you're probably more familiar with the twm code than anyone here. I
would love to see you take over upstream twm and bring it into the
modern world.

--
Dan
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: [ANNOUNCE] xorg-server 1.7.99.2

[Dan Nicholson]

On Sun, Dec 20, 2009 at 5:19 AM, Stephan Raue mailingli...@openelec.tv wrote:
 Hi all,

 when i am crosscompiling xorg-server i get an error from configure:
 checking for /etc/X11/fontpath.d... configure: error: cannot check for
 file existence when cross compiling

 is it possible to make this easyer for crosscompiling without patching
 configure.ac and configure in an release?

That's just the way AC_CHECK_FILE works. Since you're cross-compiling,
it doesn't think it's appropriate to check for files on the build
system to determine behavior. It continues, right? It should just give
you the fallback behavior. If you want to specify the fontpath, use
--with-default-font-path.

--
Dan
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: [ANNOUNCE] xorg-server 1.7.99.2

[Dan Nicholson]

On Sun, Dec 20, 2009 at 11:24 AM, Stephan Raue mailingli...@openelec.tv wrote:
 Zitat von Dan Nicholson dbn.li...@gmail.com:

 On Sun, Dec 20, 2009 at 5:19 AM, Stephan Raue mailingli...@openelec.tv
 wrote:

 Hi all,

 when i am crosscompiling xorg-server i get an error from configure:
 checking for /etc/X11/fontpath.d... configure: error: cannot check for
 file existence when cross compiling

 is it possible to make this easyer for crosscompiling without patching
 configure.ac and configure in an release?

 That's just the way AC_CHECK_FILE works. Since you're cross-compiling,
 it doesn't think it's appropriate to check for files on the build
 system to determine behavior. It continues, right? It should just give
 you the fallback behavior. If you want to specify the fontpath, use
 --with-default-font-path.

 no it doesnt continue, and i have already set --with-default-font-path ...

It looks like there's multiple issues with this approach, but the
attached should fix the cross compiling problem. We also need to
address the fact the file test won't resolve all the way when
$sysconfdir is not specified on the command line. E.g.,
sysconfdir=${prefix}/etc by default, and then test -r
${sysconfdir}/X11/fontpath.d fails:

checking for ${prefix}/etc/X11/fontpath.d... no

--
Dan


cross-fontpath.patch
Description: application/mbox
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: xinput: Do I want xorg.conf? Do I want hal? Do I want udev?

[Dan Nicholson]

On Thu, Nov 26, 2009 at 3:55 PM, Peter Hutterer
peter.hutte...@who-t.net wrote:
 On Thu, Nov 26, 2009 at 09:34:38AM -0500, Tom Horsley wrote:
 On Thu, 26 Nov 2009 09:19:52 -0500
 Tom Horsley wrote:

  That might be the very thing! There is even a fedora package
  for it. I'm off to crank it up and see if I can get it
  to work they way I want. Thanks!

 Unfortunately, just like gnome-mouse-properties, there is
 nothing in this tool that will handle the button mapping or
 drag lock changes I want :-(.

 As with much of input, we've been in a transitional phase for the last years
 to turn from the old static system into a more flexible and dynamic one. X
 is on the bottom of the stack, so any change needs to be reflected in the
 upper layers - and they're not necessarily there yet.

 We're slowly catching up, but not as quick as some would like us and many
 options are still not exposed - drag lock being one example.

 So here's the cardhouse:
 As you said, the single xorg.conf file isn't really suited to evdev (or the
 other way round). The input system is now aimed at per-device, per-session
 (runtime) configuration. Static configuration is possible, but discouraged.
 You can dop keys into the HAL configuration, but that'll go away eventually
 with udev.
 The best proposal for static configuration were Dan's xorg.conf.d patches
 but I don't know how much they have progressed in the last months. Maybe Dan
 can comment on that?

Just finished it yesterday (been too busy), and it seems to work
correctly. I'll post it shortly.

--
Dan
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: asciidoc requirement for man pages ?

[Dan Nicholson]

2009/10/22 Frédéric L. W. Meunier lists2...@pervalidus.net:
 After compiling all 7.5 libraries, I noticed that in the man3
 directory there were old man pages. All belonged to libXi
 1.2.1.

 When you compile 1.3 (from tarballs, not git), do you need xmlto
 AND asciidoc to install the man pages ?

 I have xmlto, but not asciidoc, and configure returned

 checking for xmlto... /usr/local/bin/xmlto
 checking for asciidoc... no
 configure: WARNING: xmlto or asciidoc not found - cannot create man pages 
 without it

 xmlto or asciidoc

 And are all man pages moving to it in the near future, or it's
 just libXi ?

The man pages are generated from asciidoc/xmlto, but the generated
pages should be in the tarball. Unfortunately the Makefile prevents
them from being installed if you don't these tools (even though you
don't need them). The culprit is this commit:

http://cgit.freedesktop.org/xorg/lib/libXi/commit/?id=e43d88541e815aa64108a6c5bc3dae5816c822dc

I had this working correctly at some point. I'll try to fix it up so
that it does the right thing either for people building from git or
from tarballs.

--
Dan
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: xorg error : Failed to activate core devices

[Dan Nicholson]

On Sat, Oct 10, 2009 at 4:53 AM, Peter Hutterer
peter.hutte...@who-t.net wrote:
 On Sat, Oct 10, 2009 at 02:28:03PM +0800, yue315012-...@yahoo.com.cn wrote:
 I compiled Xorg 1.7.0 for my Geexbox. When start Xorg, it always said
   (EE) Error compiling keymap (server-0)
   (EE) XKB: Couldn't compile keymap
   XKB: Failed to compile keymap
   Keyboard initialization failed. This could be a missing or incorrect setup 
 of xkeyboard-config.

 this could be caused a missing or incorrect setup of xkeyboard-config :) the
 easiest way to fix that is to install xkeyboard-config into the same prefix
 as the server.

 otherwise, grep for XKB_BASE_DIRECTORY in config.log, make sure
 xkeyboard-config is installed there.
 grep for XKB_COMPILED_DIR in config.log, make sure this directory is
 writeable.
 grep for XKB_BIN_DIRECTORY, make sure xkbcomp is in that directory.

For this last one, is there any reason why we don't do
AC_PATH_PROG(XKBCOMP, xkbcomp, '${bindir}/xkbcomp') in the server? I
know that xkbcomp should die a fiery death, but in the meantime I
think that would make the user experience nicer.

--
Dan
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: Finishing the X11R7.5 katamari

[Dan Nicholson]

On Fri, Oct 2, 2009 at 7:15 PM, Alan Coopersmith
alan.coopersm...@sun.com wrote:


 Jeremy Huddleston wrote:
 If anyone disagrees with these, or the module versions listed as being
 a stable, X11R7.5-compatible version that should be included in the
 katamari,
 now is the time to speak, as at the rate we're going, we should have the
 X11R7.5 release finished by this time next week.
  ...
                          xineramaproto    1.1.2  1.2
                                 xinput    1.3.0    *

 xinit seems to be omitted... and it could use a bump too.

 xinit was not on the X11R7.4 katamari modules list, but is on my list of
 modules needing a release made.   I'm not sure why it was removed - perhaps
 because the expectation is most users get X11 started via a display manager
 like gdm/kdm now?   Though that wouldn't apply to Cygwin  MacOS X users,
 so xinit would seem to be a core part of their window system.

That was basically it. xinit was still in and I mentioned that there
could be a problem because half the apps being run in the default
xinitrc had been removed from the katamari. Ajax solved that problem
by removing xinit from the katamari. :)

--
Dan
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: [Q] Xorg VNC driver?

[Dan Nicholson]

On Wed, Sep 23, 2009 at 7:19 AM, Alan Hourihane al...@fairlite.co.uk wrote:
 On Wed, 2009-09-23 at 07:00 -0700, Dan Nicholson wrote:
 On Wed, Sep 23, 2009 at 6:20 AM, Alan Hourihane al...@fairlite.co.uk wrote:
 
  When 1.7 is tagged for release I'll import that into xf4vnc and fixup
  accordingly.

 Alan,

 Have you given any thought to moving xf4vnc into git repos? It would
 make the merging much simpler, and it would allow others to keep up
 with xorg master much easier. Obviously, it's your project, but it
 would seem like a big win.

 Now that SF has git, I'll do that.

 I'll let you know when it's done.

Great. To facilitate merging with xorg-server, you may want to have
the server in it's own repository. If you want to pursue that, the
git-split script can be used to split the repo and keep history.

http://people.freedesktop.org/~jamey/git-split
http://github.com/rjp/git-split

--
Dan
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: Problem regarding configuring X server.

[Dan Nicholson]

On Fri, Sep 18, 2009 at 5:37 AM, Amey Moghe amey1...@gmail.com wrote:
 As I mentioned in my earlier post, I am configuring X server for MPX . After
 configuration of x server for MPX ,I tried to run it by executing following
 command

 sudo startx -- /opt/gfx-test/bin/Xorg -verbose :1

 I came across following error:

 (EE) XKB: Couldn't open rules file /opt/gfx-test/share/X11/xkb/
 rules/base
 XKB: Failed to compile keymap
 Keyboard initialization failed. This could be a missing or incorrect setup
 of xkeyboard-config.

 Fatal server error:
 Failed to activate core devices.


 For the above error I tried to install xkeyboard-config in /opt/gfx-test but
 I am facing following error:

 (
   I am using following variables:
   PKG_CONFIG_PATH=/opt/gfx-test/lib/pkgconfig
   ACLOCAL=aclocal -I /opt/gfx-test/share/aclocal
 )

 intltoolize: 'intltool-extract.in' exists: use '--force' to overwrite
 intltoolize: 'intltool-merge.in' exists: use '--force' to overwrite
 intltoolize: 'intltool-update.in' exists: use '--force' to overwrite
 intltoolize: 'po/Makefile.in.in' exists: use '--force' to overwrite
 autoreconf: Entering directory `.'
 autoreconf: configure.in: not using Gettext
 autoreconf: running: aclocal
 configure.in:47: warning: macro `AM_GLIB_GNU_GETTEXT' not found in library
 autoreconf: configure.in: tracing
 autoreconf: configure.in: not using Libtool
 autoreconf: running: /usr/bin/autoconf
 autoreconf: configure.in: not using Autoheader
 autoreconf: running: automake --add-missing --copy --no-force
 rules/Makefile.am:184: `%'-style pattern rules are a GNU make extension
 autoreconf: Leaving directory `.'
 checking for a BSD-compatible install... /usr/bin/install -c
 checking whether build environment is sane... yes
 checking for a thread-safe mkdir -p... /bin/mkdir -p
 checking for gawk... no
 checking for mawk... mawk
 checking whether make sets $(MAKE)... yes
 checking whether to enable maintainer-specific portions of Makefiles... yes
 checking for xkbcomp... /usr/bin/xkbcomp
 checking for style of include used by make... GNU
 checking for gcc... gcc
 checking for C compiler default output file name... a.out
 checking whether the C compiler works... yes
 checking whether we are cross compiling... no
 checking for suffix of executables...
 checking for suffix of object files... o
 checking whether we are using the GNU C compiler... yes
 checking whether gcc accepts -g... yes
 checking for gcc option to accept ISO C89... none needed
 checking dependency style of gcc... none
 checking for intltool = 0.30... 0.37.1 found
 checking for xgettext... /usr/bin/xgettext
 checking for msgmerge... /usr/bin/msgmerge
 checking for msgfmt... /usr/bin/msgfmt
 checking for perl... /usr/bin/perl
 checking for XML::Parser... ok
 ./configure: line 3877: AM_GLIB_GNU_GETTEXT: command not found

This is an autoconf macro in the file
/usr/share/aclocal/glib-gettext.m4. I'm not sure why xkeyboard-config
needs it, but it's in the glib development package. I don't know what
distro you're on, but it's glib2-devel on fedora.

--
Dan
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: Blank screen on starting X

[Dan Nicholson]

On Tue, Sep 15, 2009 at 10:59 AM, Alan Coopersmith
alan.coopersm...@sun.com wrote:
 Flittigs at PICT wrote:
 Now, to have a gdm  and other stuff running, on starting X, should I
 write a script, as in some more piece of code along with the startx
 command?

 No, you should just start gdm, and let it start X for you.

Just make sure you setup gdm to use your Xorg in /opt/MPX (it will
default to /usr/bin/X or similar). I don't recall the exact way to do
this on newer gdm, but documentation is here:

http://library.gnome.org/admin/gdm/

--
Dan
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: generic touchscreen calibration

[Dan Nicholson]

On Mon, Sep 14, 2009 at 12:26 PM, Tias t...@ulyssis.org wrote:
 Søren Hauberg wrote:
 Hi,

 2009/9/10 Tias t...@ulyssis.org:
 In the end, I had to hack up the ancient tkxinput because it was the only
 device independent calibrator (it uses Xinput to read the coordinates). On
 the other hand, I was impressed by the simplicity of the calibrator that
 Soren Hauberg sent to this list in july (thread titled 'Evdev touchscreen
 calibration?'), although it was written for usbtouchscreen driven devices
 specifically.


 I figured that a generic calibration program should be device independent
 when reading calibration data, and device dependent in how to use the data.

 I've adapted Soren's calibrator to do exactly this: it reads the current
 calibration from Xinput. When the usbtouchscreen driver is used, it
 dynamically changes the calibration. Otherwise it prints the new calibration
 data in xorg.conf format on stdout. Other actions would be possible too,
 like rewriting the xorg.conf directly, maybe even use some new evdev/Xinput2
 goodness ?

 It's been quite a while since I was working on this (I changed job, so
 I never got to finish this), so my comments might not actually be
 true.

 First, I'd like to add that I'm glad you're spending time on
 resurecting my old code. Thanks :-)

 Second, part of this code was added before the 'evdev' X11 driver got
 support for touchscreens. This driver allows you to set the
 calibration parameters at run-time without making changes to xorg.conf
 (hence no restart of X). I think the calibration tool should use this
 instead of working with xorg.conf.

 Wauw, it would be great to use this new 'evdev' functionality!
 Where can I find out the details about this ? Or could somebody provide
 a code sample or something ?

It makes use of the XI Properties support in newer servers. See the
SUPPORTED PROPERTIES section in evdev(4) for the property names. You
can then use the xinput tool to adjust the properties at run time. You
could probably look at the xinput source code for inspiration on
adjusting the properties from a new gui app.

--
Dan
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: File `-lselinux' does not exist.

[Dan Nicholson]

On Sun, Aug 16, 2009 at 4:52 PM, Dan Nicholsondbn.li...@gmail.com wrote:
 On Sun, Aug 16, 2009 at 2:11 PM, Justin Mattockjustinmatt...@gmail.com 
 wrote:
 I've been racking my brain on this for a few days
 without any results.
 I can compile the xserver normally, but as seen as I enable
 selinux I get an error during compilation time.

 make -d shows this:

 No need to remake target `../../xkb/libxkb.la'.
    Considering target file `-lselinux'.
     File `-lselinux' does not exist.

 Try commenting the automake rule for libxorg_la_DEPENDENCIES in
 hw/xfree86/Makefile.am. The problem is that libxorg_la_DEPENDENCIES is
 defined as libxorg_la_LIBADD, which (rightly) includes -lselinux.
 However, DEPENDENCIES are used as make prerequisites, so make will try
 to find a file named -lselinux. DEPENDENCIES and LIBADD need to be
 untangled so that external libraries don't appear as make prereqs.

Try this (untested) patch.

--
Dan
diff --git a/configure.ac b/configure.ac
index 3287f9a..e7c0596 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1337,7 +1337,7 @@ if test x$XORG = xyes; then
 	XORG_OSINCS='-I$(top_srcdir)/hw/xfree86/os-support -I$(top_srcdir)/hw/xfree86/os-support/bus -I$(top_srcdir)/os'
 	XORG_INCS=$XORG_DDXINCS $XORG_OSINCS
 	XORG_CFLAGS=$XORGSERVER_CFLAGS -DHAVE_XORG_CONFIG_H
-	XORG_LIBS=$COMPOSITE_LIB $FIXES_LIB $XEXTXORG_LIB $GLX_LIBS $RANDR_LIB $RENDER_LIB $DAMAGE_LIB $MIEXT_DAMAGE_LIB $MIEXT_SHADOW_LIB $XI_LIB $XKB_LIB $SELINUX_LIB
+	XORG_LIBS=$COMPOSITE_LIB $FIXES_LIB $XEXTXORG_LIB $GLX_LIBS $RANDR_LIB $RENDER_LIB $DAMAGE_LIB $MIEXT_DAMAGE_LIB $MIEXT_SHADOW_LIB $XI_LIB $XKB_LIB
 
 	dnl ==
 	dnl symbol visibility
@@ -1390,7 +1390,7 @@ if test x$XORG = xyes; then
 	AC_CHECK_FUNCS([pci_device_is_boot_vga])
 	LIBS=$SAVE_LIBS
 	CFLAGS=$SAVE_CFLAGS
-	XORG_SYS_LIBS=$XORG_SYS_LIBS $PCIACCESS_LIBS $DLOPEN_LIBS $GLX_SYS_LIBS
+	XORG_SYS_LIBS=$XORG_SYS_LIBS $PCIACCESS_LIBS $DLOPEN_LIBS $GLX_SYS_LIBS $SELINUX_LIB
 	XORG_CFLAGS=$XORG_CFLAGS $PCIACCESS_CFLAGS
 
 	case $host_os in
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: File `-lselinux' does not exist.

[Dan Nicholson]

On Sun, Aug 16, 2009 at 6:02 PM, Justin P.
Mattockjustinmatt...@gmail.com wrote:

 ooops!
 (as you can see my brain is mush, from looking
 at this all day). After doing the autoreconf
 with your patch finally the xserver compiled all the way through.
 (nice catch).

Is Xorg actually linked to libselinux? Just want to make sure before I
push the patch.

--
Dan
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: Evdev touchscreen calibration?

[Dan Nicholson]

On Wed, Jul 22, 2009 at 6:24 AM, Florian Echtlerf...@butterbrot.org wrote:
 Hello everyone,

 I've recently written an input event driver for a touchscreen, and it's
 working out-of-the box with the evdev driver. However, the scaling is a
 bit off, so I'd like to do a four-point calibration and set the Evdev
 Axis Calibration property accordingly. Is there a tool which does that?
 I've only found ts_calibrate so far, which is just for framebuffer
 devices.

You can set any input properties with a recent xinput tool.

--
Dan
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: xkeyboard-config woes/keymap compile errors with new Git Xorg stack build

[Dan Nicholson]

On Mon, Jul 20, 2009 at 3:04 PM, Joel Feinerjafei...@gmail.com wrote:
 I went to rebuild my Xorg stack from Git.  Since my old build has built
 up some cruft from being around for a while, I decided to make a new
 build into an empty install directory.  That is, I am rebuilding from
 scratch.  Everything worked except that when I run X, it dies
 complaining that it can't parse the XKB map:

 (EE) Error compiling keymap (server-0)
 (EE) XKB: Couldn't compile keymap
 XKB: Failed to compile keymap
 Keyboard initialization failed. This could be a missing or incorrect
 setup of xkeyboard-config.

That means that xkbcomp failed. Is there anything on stdout? Do you
have xkbcomp in /usr/local/bin? Sadly, the server build hardcodes the
xkbcomp location as $bindir/xkbcomp. You can make a symlink to where
your system's xkbcomp is located if you don't want to build a new one.

--
Dan
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: setting evdev properties from HAL?

[Dan Nicholson]

2009/7/1 Asbjørn Sannes a...@sannes.org:
 hi,

 I'm trying to make an fdi file that will do the equivalent of (which
 works great):
 xinput set-int-prop ITM Inc USB Touch Panel Evdev Axis Inversion 8 1 1
 xinput set-int-prop ITM Inc USB Touch Panel Evdev Axes Swap 8 1
 xinput set-int-prop ITM Inc USB Touch Panel Evdev Axis Calibration
 32 263 3850 152 3914

 For Evdev Axis Inversion I have found I can do:
 merge key=input.x11_options.InvertX type=stringtrue/merge
 merge key=input.x11_options.InvertY type=stringtrue/merge

 and for Evdev Axes Swap I can do:
 merge key=input.x11_options.SwapAxes type=stringtrue/merge

 But for Evdev Axis Calibration I have not found anything that works ..

 Any hints and suggestions are welcome :)

 I am currently running Xorg 1.6.1, evdev 2.2.2 and hal 0.5.12rc1 (and
 gentoo -r6).

Unfortunately, I doesn't seem that the calibration property has an
equivalent xorg.conf option since it's intended for runtime
calibration.

--
Dan
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: How to run the X xserver in a chroot environment

[Dan Nicholson]

On Thu, Jun 11, 2009 at 1:54 PM, Tino Keiteltino.keitel+x...@tikei.de wrote:
 Hi,

 as the Intel driver is very fragile recently, I want to test it in a
 chroot environment, and keep the stable 2.4 driver in the normal
 system. This implies that I also keep an old version of the X server in
 the normal system. So I installed a chroot system. But HAL can not be
 used in a chroot, and without HAL, I get not input devices in the X
 server.

You can easily just install a temporary X to another location and use
it without chrooting. I think this is the way most of the developers
test X. You can even leverage most of the client side that's already
installed and just focus on server/drivers.

--
Dan
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: Strange issue with hal and Xorg

[Dan Nicholson]

On Fri, Jun 12, 2009 at 5:46 AM, Matt Hayesdomin...@slackadelic.com wrote:
 Hrm.. so where the heck is the 32 buttons coming from?  That's very
 odd and causes mapping of buttons to be a pita.

The evdev driver. Perhaps you were using the mouse driver in xorg.conf?

--
Dan
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: X.org release engineering?

[Dan Nicholson]

On Mon, Jun 8, 2009 at 1:20 PM, Adam Jacksona...@nwnk.net wrote:

 Testing is... informal is the polite word.  Nobody's stepped up to do it
 rigorously, so no one does it.

Peter poked me a while ago to work on autotooling xtest. I have it
just about working nicely to where you just run make check and sit
back while tons of tests fail. Should be ready for public consumption
in a week or so even if some of the edges are still pretty sharp.

--
Dan
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: XI2 pull warning

[Dan Nicholson]

On Tue, Jun 2, 2009 at 8:24 AM, Thomas Jaeger thjae...@gmail.com wrote:
 Peter Hutterer wrote:

 actually, the reason for this could be a missing dependency in the man
 pages. If you can reproduce this error, just check the Makefile.am for the
 dependency setup for the file it fails on. I've tried triggering it but
 without success.

 My theory is that it's a race condition, where due to the recursive call
 of make the same man page is built at the same time by both processes
 and then the second mv fails.

Can you show the error?

--
Dan
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: Error During Autoconf

[Dan Nicholson]

On Sat, May 30, 2009 at 10:07 PM, Joe Sprankle jspran...@awlship.com wrote:
 On Sat, 2009-05-30 at 21:37 -0700, Dan Nicholson wrote:
 On Sat, May 30, 2009 at 8:11 PM, Joe Sprankle jspran...@awlship.com wrote:
  Hi all,
  Brand new to this.
  I'm attempting to learn to build kdrive and not off to a good start.
  Configure.ac says to run autoconf to create configure script.
  I'm receiving the following error:
 
  f...@foo:~/Desktop/xorg-server-1.6.1.901$ autoconf
  configure.ac:31: error: possibly undefined macro: AM_INIT_AUTOMAKE
       If this token and others are legitimate, please use
  m4_pattern_allow.
       See the Autoconf documentation.


 Sounds like you don't have automake installed.
 automake --version
 automake (GNU automake) 1.10.2
 Copyright (C) 2008 Free Software Foundation, Inc.
 License GPLv2+: GNU GPL version 2 or later
 http://gnu.org/licenses/gpl.html
 This is free software: you are free to change and redistribute it.
 There is NO WARRANTY, to the extent permitted by law.

Right, now I remember what the issue is. You need to run aclocal first
so that the automake m4 macros are pulled in. However, just run the
autogen.sh script or autoreconf -iv.

--
Dan
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: Error During Autoconf **UPDATE**

[Dan Nicholson]

On Sat, May 30, 2009 at 11:04 PM,  jspran...@awlship.com wrote:



  ---Original Message---
  From: Dan Nicholson dbn.li...@gmail.com
  Subject: Re: Error During Autoconf
  Sent: May 31 '09 04:37

  On Sat, May 30, 2009 at 8:11 PM, Joe Sprankle jspran...@awlship.com wrote:
   Hi all,
   Brand new to this.
   I'm attempting to learn to build kdrive and not off to a good start.
   Configure.ac says to run autoconf to create configure script.
   I'm receiving the following error:
  
   f...@foo:~/Desktop/xorg-server-1.6.1.901$ autoconf
   configure.ac:31: error: possibly undefined macro: AM_INIT_AUTOMAKE
        If this token and others are legitimate, please use
   m4_pattern_allow.
        See the Autoconf documentation.

  Sounds like you don't have automake installed. You'll need autoconf,
  automake and libtool to work with the git sources. Additionally,
  you'll need any other X modules that the server depends on.

  http://xorg.freedesktop.org/wiki/Development/git

  It's also very probably Ubuntu has kdrive. Look for Xephyr.

  --
  Dan
  ___
  xorg mailing list
  x...@lists.freedesktop.org
  http://lists.freedesktop.org/mailman/listinfo/xorg

 Dependencies killed the cat1
 I installed a xorg-dev package and autoconf runs with only the following 
 error:

 checking for GL... configure: error: Package requirements (glproto = 1.4.9 
 gl = 7.1.0) were not met:

 No package 'gl' found

That's mesa's libGL. Probably you can use your distro's GL (libGL-dev
or something). Otherwise, read the Development/git page I pointed you
to. It shows the correct order to build all the modules so you can get
a xserver.

--
Dan
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: [cgit] No repositories found

[Dan Nicholson]

On Sun, May 31, 2009 at 3:23 PM, Paul Menzel
paulepan...@users.sourceforge.net wrote:
 Dear list,


 from [1] I click on 2009-02-26 Intel video driver patch [2] and get the
 following message.

        No repositories found

 Is that behavior correct?


 Thanks,

 Paul


 [1] 
 http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/log/src/i810_driver.c
 [2] 
 http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=f53bdad1412f841075232455837578f00709c6ef

Seems like it's a probably a bug in cgit. If you shorten the id, you
can see the commit.

http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=f53bdad1

So, it's there, but someone would probably have to dig into cgit to
see where it's failing.

--
Dan
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: Xorg support to import options for non-Input sections?

[Dan Nicholson]

On Tue, May 12, 2009 at 1:58 AM, Kevin Stange ke...@simguy.net wrote:
 I am trying to find out whether I can define options for non-input
 devices via HAL fdi files.  My goal is to specify settings for sections
 like my video card, monitor or screen.  I haven't been able to find
 anything that seems relevant anywhere and all examples I have found are
 exclusively related to keyboard or pointer settings.

 Is this possible (or planned)?

No. Only the input devices pick up configuration through HAL, and I
think people would prefer if that went away some day.

--
Dan
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: Xorg support to import options for non-Input sections?

[Dan Nicholson]

On Tue, May 12, 2009 at 10:23 AM, Kevin Stange ke...@simguy.net wrote:
 Dan Nicholson wrote:
 On Tue, May 12, 2009 at 1:58 AM, Kevin Stange ke...@simguy.net wrote:
 I am trying to find out whether I can define options for non-input
 devices via HAL fdi files. Â My goal is to specify settings for sections
 like my video card, monitor or screen. Â I haven't been able to find
 anything that seems relevant anywhere and all examples I have found are
 exclusively related to keyboard or pointer settings.

 Is this possible (or planned)?

 No. Only the input devices pick up configuration through HAL, and I
 think people would prefer if that went away some day.

 So you're saying this HAL method is widely (or narrowly, but by the
 right people) disliked?  Using Gentoo it seems to be encouraged, and
 I've seen indications other distros (like Ubuntu) have picked up the
 technique as well.

 The reason I kind of like this method is because I don't have to define
 the device in the xorg.conf, so if it's not present/detected I'm
 basically not telling xorg to expect it (or so it seems to me).  Does
 xorg keep track of relevant sections should the devices appear via HAL
 later to load in their options?

Right, those are the reasons the HAL fdi is being used now for
configuration and it's the way you should be doing it if you want
hotpluggable input devices. The reason it's disliked is because it's
an abuse of HAL's fdi system. No one has a plan for a better system
wide configuration as far as I know, though. I have an idea for
specifying an InputClass in xorg.conf, but it only exists in my
mind. :)

What is more being pushed for is that users just setup the input
devices in their session rather than relying on a system-wide
configuration. The input properties code supports this (try the xinput
app), but it's not widely used yet.

 I suppose the definitions are necessarily more important for input
 devices which get hotplugged a lot more than video cards.

The HAL hotplugging is only wired up for input devices. I think for
video cards (or more likely outputs like monitors and projectors), the
idea is to use drm to get notification from the kernel when hotplug
events occur, but I could be way off base there.

--
Dan
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: Xorg support to import options for non-Input sections?

[Dan Nicholson]

On Tue, May 12, 2009 at 3:33 PM, Robert Noland rnol...@2hip.net wrote:
 On Tue, 2009-05-12 at 15:24 -0700, Dan Nicholson wrote:
 On Tue, May 12, 2009 at 2:41 PM, Alan Coopersmith
 alan.coopersm...@sun.com wrote:
  Colin Guthrie wrote:
  'Twas brillig, and Kevin Stange at 12/05/09 18:23 did gyre and gimble:
  So you're saying this HAL method is widely (or narrowly, but by the
  right people) disliked?  Using Gentoo it seems to be encouraged, and
  I've seen indications other distros (like Ubuntu) have picked up the
  technique as well.
 
  HAL will eventually be phased out in favour of getting more direct
  information from udev. I'm not sure how that will impact the Xorg side
  of things but i'd imagine the end solution will be in some way related
  to udev. (this is just a guess tho)
 
  And for non-Linux systems?   HAL is OS-agnostic, udev seems very Linux
  specific.

 Well, there's DeviceKit, but I don't think anyone has any plans for
 DeviceKit-input or DeviceKit-graphics. I'd personally like to see an
 abstraction layer rather than putting one into Xorg.

 You don't consider HAL an reasonable abstraction layer?

Not when its creators are trying to get rid of it.

--
Dan
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: Xorg support to import options for non-Input sections?

[Dan Nicholson]

On Tue, May 12, 2009 at 4:41 PM, Robert Noland rnol...@2hip.net wrote:
 On Tue, 2009-05-12 at 16:16 -0700, Dan Nicholson wrote:
 On Tue, May 12, 2009 at 3:33 PM, Robert Noland rnol...@2hip.net wrote:
  On Tue, 2009-05-12 at 15:24 -0700, Dan Nicholson wrote:
  On Tue, May 12, 2009 at 2:41 PM, Alan Coopersmith
  alan.coopersm...@sun.com wrote:
   Colin Guthrie wrote:
   'Twas brillig, and Kevin Stange at 12/05/09 18:23 did gyre and gimble:
   So you're saying this HAL method is widely (or narrowly, but by the
   right people) disliked?  Using Gentoo it seems to be encouraged, and
   I've seen indications other distros (like Ubuntu) have picked up the
   technique as well.
  
   HAL will eventually be phased out in favour of getting more direct
   information from udev. I'm not sure how that will impact the Xorg side
   of things but i'd imagine the end solution will be in some way related
   to udev. (this is just a guess tho)
  
   And for non-Linux systems?   HAL is OS-agnostic, udev seems very Linux
   specific.
 
  Well, there's DeviceKit, but I don't think anyone has any plans for
  DeviceKit-input or DeviceKit-graphics. I'd personally like to see an
  abstraction layer rather than putting one into Xorg.
 
  You don't consider HAL an reasonable abstraction layer?

 Not when its creators are trying to get rid of it.

 Well, I think that our gnome folks are planning to support DeviceKit as
 it's replacement.

 If we are going to support dynamic device detection, then I think the
 most reasonable approach is to support an OS independent or at least
 cross platform API.

Right. The issue is that DeviceKit is not a catch all for any piece of
hardware that could show up like HAL is. There are smaller niche DKs
like DeviceKit-disks and DeviceKit-power right now. Like I said, I
don't think anyone is planning DeviceKit-input to abstract input
devices.

--
Dan
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: multiseat, -sharevts, and suspend/hibernate

[Dan Nicholson]

On Tue, May 12, 2009 at 3:30 PM, McDonald, Michael-p7438c
michael.mcdon...@gdc4s.com wrote:


 -Original Message-
 From: Tiago Vignatti [mailto:vigna...@freedesktop.org]
 Sent: Tuesday, May 12, 2009 2:02 PM
 To: McDonald, Michael-p7438c
 Cc: x...@freedesktop.org
 Subject: Re: multiseat, -sharevts, and suspend/hibernate

 McDonald, Michael-p7438c escreveu:
    I'm confused. What does rootless servers have to do with
 multiseat?

 In the current implementation, multiseat implies in several
 servers in
 parallel, which in turn implies in hardware accesses in
 parallel (mostly
 not coordinated by anyone), which in turn mess your system. Uoow!


  I understand the difficulties in running multiple X servers. I don't
 understand how rootless servers are going to make it easier.

If your server is rootless, than by necessity it must properly obtain
resources and will not be allowed to stomp on another processes'
resources.

--
Dan
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: multiseat, -sharevts, and suspend/hibernate

[Dan Nicholson]

On Tue, May 12, 2009 at 5:37 PM, McDonald, Michael-p7438c
michael.mcdon...@gdc4s.com wrote:


 -Original Message-
 From: Dan Nicholson [mailto:dbn.li...@gmail.com]
 Sent: Tuesday, May 12, 2009 4:51 PM
 To: McDonald, Michael-p7438c
 Cc: vigna...@freedesktop.org; x...@freedesktop.org
 Subject: Re: multiseat, -sharevts, and suspend/hibernate

 If your server is rootless, than by necessity it must properly obtain
 resources and will not be allowed to stomp on another processes'
 resources.

  Ahhh. You're defining the kernel's KMS screen as the root window,
 therefore all window systems, X included, are rootless. Got it. Thanks.

No, I was thinking more that if the xserver is not run by root, it
can't just have its way with the PCI resources. Then it can't wreak
havoc on what another xserver is doing with them, either. So, I think
that Tiago means that if the xserver is rootless, then it will
implicitly be accessing the hardware properly though the kernel and
will not interfere with another xserver trying to access the hardware.

--
Dan
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: AllowEmptyInput and HAL (SOLVED!!!)

[Dan Nicholson]

On Fri, May 8, 2009 at 10:46 AM, Phil Endecott
spam_from_x...@chezphil.org wrote:
 Finally solved, after something like 60 hours of hacking.

 My libX11.so was old.  This caused xkbcomp to fail to parse the keymap
 files - it didn't recognise ISO_Level5 stuff.  It looks like xkbcomp
 generated a keymap with some sort of Any+Any definition that caused
 every key to toggle the modifiers.

 This morning I attempted to purge and re-install all of my X-related
 Debian packages.  I got rid of the server stuff but I couldn't get rid
 of the client libraries because that would cause huge numbers of client
 programs to be removed too.  But I didn't worry about that because the
 problem was clearly on the server side.  I eventually latched on to
 the level 5 warnings and started looking for them with strings.  Then
 ldd on xkbcomp pointed at the guilty library.

 I'm surprised that it didn't work with the xserver that I built using
 khbuild.  Presumably this is because that was still using libraries
 from /usr/lib, not the ones that it had just built and put somewhere in
 $HOME.  Is that an rpath issue with khbuild?

It's because xkbcomp links with libX11.so, not the server. However, if
you built xkbcomp and Xlib from jhbuild, it should pick up the new
Xlib during the xkbcomp build. And libtool usually adds a rpath if it
detects one of the libraries is outside of the standard linker path.
You'd have to inspect what jhbuild is doing if that's not the case.

 What can we learn?

 - Debian needs a more strongly-versioned dependency between some of its
 packages.  I'll take that up with them (if the appropriate people are
 already reading this, please let me know).

 - xkbcomp, when called by the server, claims that xkbcomp errors are
 not fatal to the server.  And only some of its messages appear in the
 X log file.  I feel that this particular error should be considered
 fatal.  And ideally, the consequence of an unrecognised keysym should
 not be the Any Key effect that I got.  (Is the person responsible for
 xkbcomp reading this?).

No one is really responsible for xkbcomp currently. The entire
interaction with xkbcomp by the server is a complete eye sore. I've
been working to make this go away, but it took a lot of surgery and
hasn't been reviewed yet.

--
Dan
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: [PATCH] app/xinit: make startx's $? a useful value

[Dan Nicholson]

On Wed, Feb 11, 2009 at 3:18 PM, Andres Salomon dilin...@queued.net wrote:

 When startx fails to start X, it's most likely xinit that failed.  xinit
 returns a proper return code (1), but that gets clobbed in the startx
 script by clean-up commands.  This patch saves $? from xinit and forces
 startx to exit with that value.

 This way, if startx actually fails to start X, $? reflects that.

 Signed-off-by: Andres Salomon dilin...@debian.org
 ---
  startx.cpp |    4 
  1 files changed, 4 insertions(+), 0 deletions(-)

 diff --git a/startx.cpp b/startx.cpp
 index f911499..05d28e3 100644
 --- a/startx.cpp
 +++ b/startx.cpp
 @@ -320,6 +320,7 @@ XINIT $client $clientargs -- $server $display 
 $serverargs
  #endif

  #endif
 +retval=$?

  if [ x$enable_xauth = x1 ] ; then
     if [ x$removelist != x ]; then
 @@ -347,3 +348,6 @@ screenrestore
  #if defined(sun)
  kbd_mode -a
  #endif
 +
 +exit $retval
 +

Sorry for not replying earlier. I think this makes sense, but it seems
that you'd also want to know if xauth (or other commands) failed, too.
Without making the script a lot more complicated, I guess this is the
right thing to do. If no one has any objections, I'll push this.

--
Dan
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: Griffin Powermate evdev setup

[Dan Nicholson]

On Tue, Apr 28, 2009 at 2:33 AM, Phil Endecott
spam_from_x...@chezphil.org wrote:
 Peter Hutterer wrote:
 On Mon, Apr 27, 2009 at 12:09:17AM +0100, Phil Endecott wrote:

      Option          DIALRelativeAxisButtons 4 5
 This option isn't supported anymore.

 OK.  I think something like this is needed, though.  If you have an
 application that actually knows about the dial axis that's fine, but
 in most cases you'll want to do some sort of mapping.  I don't see any
 mention of the mouse scroll wheel in the new evdev man page; how is
 that managed?

Read the description for EmulateWheel in evdev(4). The options are
just like the mouse driver now.

 The old driver was ugly (bitmasks etc) but useful.  I hope the new
 version hasn't thrown the baby out with the bath water.

I wouldn't worry about it. Looking at the evtest trace, I think what
you're going to get once the probing stops dropping your device is a
left mouse button and a hwheel for the dial.

 As Dan said, the device doesn't advertise a known combination of axes +
 buttons. Please run http://people.freedesktop.org/~whot/evtest.c against the
 device file and attach the output to a bug on bugs.freedesktop.org.

 Here's the output, also filed as
 http://bugs.freedesktop.org/show_bug.cgi?id=21457 :

 Input driver version is 1.0.0
 Input device ID: bus 0x3 vendor 0x77d product 0x410 version 0x400
 Input device name: Griffin PowerMate
 Supported events:
   Event type 0 (Sync)
   Event type 1 (Key)
     Event code 256 (Btn0)
   Event type 2 (Relative)
     Event code 7 (Dial)
   Event type 4 (Misc)
     Event code 1 (Pulseled)
 Grab succeeded, ungrabbing.
 Testing ... (interrupt to exit)
 Event: time 1240909108.341856, type 2 (Relative), code 7 (Dial), value -1
 Event: time 1240909108.341878, -- Report Sync 
 Event: time 1240909108.773822, type 2 (Relative), code 7 (Dial), value -1
 Event: time 1240909108.773838, -- Report Sync 
 Event: time 1240909109.029820, type 2 (Relative), code 7 (Dial), value -1
 Event: time 1240909109.029836, -- Report Sync 
 Event: time 1240909109.149823, type 2 (Relative), code 7 (Dial), value -1
 Event: time 1240909109.149839, -- Report Sync 
 Event: time 1240909109.357821, type 2 (Relative), code 7 (Dial), value 1

Is -1 turning the dial to the left and +1 turning the dial to the right?

--
Dan
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: Griffin Powermate evdev setup

[Dan Nicholson]

On Tue, Apr 28, 2009 at 8:00 AM, Phil Endecott
spam_from_x...@chezphil.org wrote:
 Dan Nicholson wrote:

 On Tue, Apr 28, 2009 at 2:33 AM, Phil Endecott
 spam_from_x...@chezphil.org wrote:

 Peter Hutterer wrote:

 On Mon, Apr 27, 2009 at 12:09:17AM +0100, Phil Endecott wrote:

      Option          DIALRelativeAxisButtons 4 5

 This option isn't supported anymore.

 OK.  I think something like this is needed, though.  If you have an
 application that actually knows about the dial axis that's fine, but
 in most cases you'll want to do some sort of mapping.  I don't see any
 mention of the mouse scroll wheel in the new evdev man page; how is
 that managed?

 Read the description for EmulateWheel in evdev(4).

 Ah OK - I don't have that in my (Debian packaged) man evdev, so I guess it's
 a recent addition.  My man page claims to be version 2.0.8.  EmulateWheel is
 what I have for my real mouse so it should do what I need.  (I do sometimes
 wonder whether more apps now work with a non-emulated wheel; when I scroll
 Firefox with my emulated wheel (or the Powermate on the old machine) it
 would take ages to catch up.  I should try it.  Maybe I need some hack so
 that some apps see the emulated events and others see axis events.)

Apps just see events from X. They have no idea how they got produced.

I use an emulated wheel on the trackpoint for my thinkpad, and it
works fine. If you're talking about scrolling the page in firefox,
it's probably the graphics that are lagging. On a local server, I
really doubt that the wheel events are taking too long to get there
unless it's something the driver is deliberately doing. If you're
concerned about this, just run xev and see if the events are really
lagging behind the hardware.

 Event: time 1240909109.149823, type 2 (Relative), code 7 (Dial), value -1
 Event: time 1240909109.149839, -- Report Sync 
 Event: time 1240909109.357821, type 2 (Relative), code 7 (Dial), value 1

 Is -1 turning the dial to the left and +1 turning the dial to the right?

 Yes.

Then once the probing gets straightened out, you should be good to go.

--
Dan
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: Griffin Powermate evdev setup

[Dan Nicholson]

On Mon, Apr 27, 2009 at 3:00 AM, Phil Endecott
spam_from_x...@chezphil.org wrote:
 Dan Nicholson wrote:

 On Sun, Apr 26, 2009 at 4:09 PM, Phil Endecott
 spam_from_x...@chezphil.org wrote:

 I have a Griffin Powermate; it's a USB knob that you can use for
 scrolling etc.  This morning the computer that it was attached to
 died.  I'm now having trouble getting to work with the substitute
 machine.

 (**) Griffin Powermate: always reports core events
 (**) Griffin Powermate: Device:
 /dev/input/by-id/usb-Griffin_Technology__Inc._Griffin_PowerMate-event-misc
 (WW) Griffin Powermate: Don't know how to use device
 (II) UnloadModule: evdev
 (EE) PreInit returned NULL for Griffin Powermate

 So, what does Don't know how to use device mean?

 This means that the evdev driver didn't recognize it to be either a
 pointer, a keyboard or a touchscreen during it's probing routine.
 Looking at a photo online, I can't really tell how you'd classify it,
 but there could certainly be bugs in the detection logic. If you have
 the source, take a look in src/evdev.c:EvdevProbe.

 http://cgit.freedesktop.org/xorg/driver/xf86-input-evdev/tree/src/evdev.c -
 Right?

Yep.

 This seems like a regression since the previous version of this driver,
 which was able to manage this device.  What can be done?

 (BTW the kernel driver is here:
 http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=drivers/input/misc/powermate.c)

Right, it's definitely a bug. The core of the xorg evdev driver was
basically rewritten (simplified greatly) for evdev-2.x, so that's why
it's regressed. Someone with more knowledge of axes, keys and buttons
will need to look into this.

In the meantime, you can poke around in that function and see if you
can get the detection to work for your device.

--
Dan
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: Griffin Powermate evdev setup

[Dan Nicholson]

On Sun, Apr 26, 2009 at 4:09 PM, Phil Endecott
spam_from_x...@chezphil.org wrote:
 Dear Experts,

 I have a Griffin Powermate; it's a USB knob that you can use for
 scrolling etc.  This morning the computer that it was attached to
 died.  I'm now having trouble getting to work with the substitute machine.

 It looks like I have the kernel stuff working OK:

 # od -x 
 /dev/input/by-id/usb-Griffin_Technology__Inc._Griffin_PowerMate-event-misc
 000 e5f3 49f4 6a00 000c 0002 0007  
 020 e5f3 49f4 6a1d 000c    
 040 e5f3 49f4 dae9 000e 0002 0007  
 060 e5f3 49f4 dafa 000e    
 100 e5f3 49f4 3897 000f 0002 0007  
 120 e5f3 49f4 38aa 000f    
 140 e5f4 49f4 34e8  0002 0007  
 160 e5f4 49f4 34f6     

 I've extracted this from the backup of the dead machine's /etc/X11/xorg.conf:

 Section InputDevice
        Identifier      Griffin Powermate
        Driver          evdev
        #Option         Device                
 /dev/input/by-id/usb-Griffin_Technology__Inc._Griffin_PowerMate-event-misc
        Option          Name                  Griffin PowerMate
        Option          SendCoreEvents        true
        Option          DIALRelativeAxisButtons 4 5
 EndSection

 Note the use of Option Name and the commented-out Option Device; I
 recall that it took me a while to get that stuff right.  I believe that
 was working with the Debian package xserver-xorg-input-evdev 1.1.2-1.

 On the substitute machine I have xserver-xorg-input-evdev 1:2.0.8-1.
 man evdev does not mention Option Name and I have the impression
 that it has gone; when I use that config fragment as-is I get an error
 in the log saying that I haven't specified a device [sorry, I can't get
 the exact message now without restarting X].  If I use the Option
 Device line (or Option Path) I instead get this:

 (**) Griffin Powermate: always reports core events
 (**) Griffin Powermate: Device: 
 /dev/input/by-id/usb-Griffin_Technology__Inc._Griffin_PowerMate-event-misc
 (WW) Griffin Powermate: Don't know how to use device
 (II) UnloadModule: evdev
 (EE) PreInit returned NULL for Griffin Powermate

 So, what does Don't know how to use device mean?

This means that the evdev driver didn't recognize it to be either a
pointer, a keyboard or a touchscreen during it's probing routine.
Looking at a photo online, I can't really tell how you'd classify it,
but there could certainly be bugs in the detection logic. If you have
the source, take a look in src/evdev.c:EvdevProbe.

--
Dan
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg