Re: libXt 1.1.1 cross compilation breakage
On 3/15/2011 1:06 PM, Jason Woodward wrote: 9ccf14fddedc11bd17b3ae30612c6f70f4cd7e14 broke cross compilation by using target specific CFLAGS when building makestrs. Reverting this commit fixes the problem. For what it is worth, as long I set the environment variables CC_FOR_BUILD, CFLAGS_FOR_BUILD and LDFLAGS_FOR_BUILD during configure, makestrs compiles correctly during cross compile. However, if I do not set these environment variables during configure, then makestrs fails to compile during cross cross compile. ___ 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] xf86-video-ati 6.14.0
Just a heads up. While the configure script allows compilation against xorg-server 1.6.2, the code depends on the xorg-server #define MONITOR_EDID_COMPLETE_RAWDATA, which was not introduced until after 1.6.2. This was solved in the intel driver by adding the following /* remain compatible to xorg-server 1.6 */ #ifndef MONITOR_EDID_COMPLETE_RAWDATA #define MONITOR_EDID_COMPLETE_RAWDATA EDID_COMPLETE_RAWDATA #endif In addition, the usage is not consistent. The radeon_output.c file and the atombios_output.c file use the deprecated EDID_COMPLETE_RAWDATA. However, the drmmode_display.c file uses MONITOR_EDID_COMPLETE_RAWDATA. ___ 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: I don't want my IR handset to act like a keyboard
On 1/12/2010 10:55 AM, Tony Houghton wrote: On Tue, 12 Jan 2010 19:25:11 +0100 Éric Piele.a.b.p...@tudelft.nl wrote: Op 10-01-10 19:04, Tony Houghton schreef: I've got a DVB card with an IR controller which appears as an input device. I want my applications to read the input device directly, not as a keyboard. Among other reasons, it's because I want to use the OK button while mplayer is running, but it generates an Enter keypress which mplayer interprets as please quit. Interestingly, someone has been complaining of exactly the opposite: http://www.kernellabs.com/blog/?p=1309 That's obsolete too now, because of X not using hal any more. Maybe in your case, what you need is just a special keymap for the remote control, and make sure that applications listen to it only via X. The trouble with that is that I like my application, boxstar, to handle the remote presses and pass on commands to mplayer via its slave interface, but mplayer grabs focus away from boxstar, depriving it of X keyboard events. I don't want to have to rely on making special exceptions in the window manager. 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. ___ 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
On 1/12/2010 2:55 PM, Dan Nicholson wrote: On Tue, Jan 12, 2010 at 2:50 PM, Tony Houghtonh...@realh.co.uk wrote: On Tue, 12 Jan 2010 13:07:03 -0800 Paul Benderpeben...@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. As Xorg is not the only input device handler, this would seem to be a bug / design flaw that should be fixed before 1.8 is released. If not, distributions will need to hack around it in their udev scripts by clearing ID_INPUT whenever they do not want Xorg to grab the device. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xorg-server with udev support instead of dbus/hal
Stephan Raue wrote: Hi, yesterday i have found an patch to lets building xorg-server with udev instead of hal/dbus for detecting input devices. i have taken an quick look in this but i cant get it work in the moment. i dont know where the patch comes from, or if this will be included in the next time. this patch can be found for minimyth, an small mediacenter distribution. because HAL will be deprecated in the next time i think we need an alternative for HAL less systems. look here: http://code.google.com/p/minimyth/source/detail?r=5787 http://code.google.com/p/minimyth/sourc ... amp;r=5799 http://code.google.com/p/minimyth/source/browse/trunk/gar-minimyth/script/meta/minimyth/files/source/rootfs/lib/udev/rules.d/06-minimyth-xorg-evdev.rules?spec=svn5799r=5799 does anyone know about this patch and the usage of this? is there an plan to add this patch to xorg-server? I am the maintainer of MiniMyth. The patch came from this post: http://lists.x.org/archives/xorg-devel/2009-September/002286.html ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xorg-server with udev support instead of dbus/hal
Stephan Raue wrote: Am 16.11.2009 22:56, schrieb Paul Bender: I am the maintainer of MiniMyth. The patch came from this post: http://lists.x.org/archives/xorg-devel/2009-September/002286.html thank you, is this working for you or do you have any problems with mm? It is working for me as well as the MiniMyth user that needed Xorg input device hotplug support in order to use his Sony PS3 BD remote. However, there is a MiniMyth for whom Xorg is crashing that is likely related to this udev support. It is likely that this can be dealt with using the appropriate udev script and xorg.conf file changes. Of course, until the cause it tracked down, I cannot be sure. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Cross compiling xorg-7.3 - /bin/sh: ../src/util/makekeys: cannot execute binary file
Stephan Raue wrote: Am 17.11.2009 03:03, schrieb john blair: I am trying to cross compile xorg-7.3 and am getting the following error: ../src/util/makekeys /usr/arm-linux-gnu/include/X11/keysymdef.h ks_tables_h /bin/sh: ../src/util/makekeys: cannot execute binary file http://www.x.org/wiki/CrossCompilingXorg discusses this problem and says that there is a patch for it. Some components need to build and run programs on the build system that generate output used in the build process. For this compnents, CC_FOR_BUILD must be set to the name of the compiler that targets the build system. The majority of these components do not correctly use CC_FOR_BUILD, but there is a patch (see below) available. have you tryed ./configure CC=your_gcc_for_target_build CC_FOR_BUILD=your_host_gcc ? But I could not find the patch on that page. Can someone tell what patches I need to apply in order to cross-compile? You might check out the patches that I use in MiniMyth (which I cross compile). You can find them at: http://code.google.com/p/minimyth/source/browse/#svn/trunk/gar-minimyth/script/xorg-7.4 ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [ANNOUNCE] libXt 1.0.7
Alan Coopersmith wrote: Thomas Petazzoni (1): Fix compilation of host tools in cross-compilation case This is not completely fixed as autotools include CPPFLAGS in the COMPILE command but there is no CPPFLAGS_FOR_BUILD to override it for compilation of host tools. As a result, it uses the wrong CPPFLAGS. It can be worked around by not adding the flags in the CPPFLAGS environment variable to the CFLAGS environment varaible and unsetting the CPPFLAGS environment variable. However, it would be cleaner to have a CPPFLAGS_FOR_BUILD environment variable. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [ANNOUNCE] libXt 1.0.7
Paul Bender wrote: Alan Coopersmith wrote: Thomas Petazzoni (1): Fix compilation of host tools in cross-compilation case This is not completely fixed as autotools include CPPFLAGS in the COMPILE command but there is no CPPFLAGS_FOR_BUILD to override it for compilation of host tools. As a result, it uses the wrong CPPFLAGS. It can be worked around by not adding the flags in the CPPFLAGS Oops. That should have been by adding the flags in the CPPFLAGS environment variable to the CFLAGS environment varaible and unsetting the CPPFLAGS environment variable. However, it would be cleaner to have a CPPFLAGS_FOR_BUILD environment variable. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xf86-video-ati 6.12.4 requires newer xextproto ?
Frédéric L. W. Meunier wrote: Is there any readon to make xf86-video-ati 6.12.4 depend on xextproto = 7.0.99.1 ? Doesn't it work with 7.0.5 ? I was using the 6.12 branch with it. I build it with xextproto 7.0.4. xf86-video-ati 6.12.4 has a check to see whether or not xextproto 7.1 exists in order to decide certain configuration information, but it builds with both. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [ANNOUNCE] xorg-server 1.6.2.901
Keith Packard wrote: On Sun, 2009-07-26 at 14:43 -0700, Keith Packard wrote: git tag: xorg-server-1.6.2.901 The intent is to make this 1.6.3 unless I hear about other important fixes which weren't on the 1.6 wiki page. Remember -- post patches to the wiki page and I'll pick them up, look them over and push them to the branch (ajax, this means you too). Does that mean the there is really no point to submitting bugs to bugs.freedesktop.org? ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [ANNOUNCE] fixesproto 4.1
Has anyone compiled this with only stable/released packages (i.e. with not *.99.* packages)? Since compiling fixesproto 4.1 with the latest released xorg packages results in the error message Package 'FixesProto' requires 'xextproto = 7.0.99.1' but version of XExtProto is 7.0.4 when compiling libXfixes 4.0.3, I suspect not. Given that fixesproto 4.1 requires at least xextproto 7.0.99.1 and the last stable xextproto was 7.0.5, giving fixesproto a stable version number would appear to be very premature. After all, how can something be considered stable when it depends on something that is not stable? ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: compiling xserver without hal
Justin Mattock wrote: quick question: if I compile xserver without hal (noticed udev 142 has no voluemid) will I be able to use the mouse and keyboard (and wireless mouse) once I startx? if so, what switches do I need to make sure are set before I compile the xserver? I build xorg-server without HAL. The two options that are relevant (as far as I can tell) to this are --disable-config-dbus --disable-config-hal In addition, when running this xorg-server, you will need to configure the input devices in your xorg.conf. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: compiling xserver without hal
On Sat, May 23, 2009 at 4:06 AM, Peter Hutterer peter.hutte...@who-t.net wrote: On Sat, May 23, 2009 at 01:00:42AM -0700, Justin Mattock wrote: On Fri, May 22, 2009 at 2:40 PM, Paul Bender peben...@san.rr.com wrote: I build xorg-server without HAL. The two options that are relevant (as far as I can tell) to this are --disable-config-dbus --disable-config-hal In addition, when running this xorg-server, you will need to configure the input devices in your xorg.conf. no you don't. the server inserts standard input device sections into the xorg.conf, so there's rarely a need to actually have that in the config. My bad. I only include the xf86-input-evdev driver in my distribution. Looking at Xorg log file, it is the lack of xf86-input-keyboard and xf86-input-mouse are what cause it to fail. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: libdrm 2.4.1
Sergio Monteiro Basto wrote: On Mon, 2008-11-03 at 21:11 +, Sergio Monteiro Basto wrote: Can I use mesa 7.2 with xserver-1.4.2 ? Fair enough to say that someone said that Mesa 7.1 needs xorg-server 1.5.x but Thanks, I found that to be true with Mesa 7.1 but not Mesa 7.2. I have changed MiniMyth so that it builds Mesa 7.2 libdrm 2.4.1 xorg-server 1.4.2 xf86-video-intel 2.5.0 xf86-video-openchrome 0.2.903 NVIDIA 169.12 Everything compiles fine. I cannot test the xf86-video-intel driver as I do not have Intel hardware. However, the xf86-video-openchrome and NVIDIA drivers work on my VIA and NVIDIA+AMD hardware respectively. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Embedded X
Juliusz Chroboczek wrote: glibc chews up what, twenty megabytes? [citation needed] $ dpkg -s libc6 locales | grep ^Installed-Size: Installed-Size: 11452 Installed-Size: 11752 That has been built for normal desktop use. I use glibc in MiniMyth and it between 2MB and 3MB. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
