Re: Detecting the used keyboard driver
Well I developed keyTouch, a program that allows the user to bind actions to extra function keys (like the Play/Pause, WWW or Zoom keys for example) on a keyboard. KeyTouch is a collection of programs. One program binds a key's scancode to a Linux keycode. So it changes the mapping inside the Linux kernel. Another program is an X client and grabs all key events of the extra function keys. So this program needs to know the X keycodes of the keys and thus it will have to translate the kernel keycode to the X keycode. These translations are different when the evdev input driver is used by the X server instead of the kbd driver. What do you mean by "query the keyboards for all properties"? Using XListInputDevices? Then there need to be different values for min_keycode, max_keycode or num_keys (or am I wrong?). These are however the same for evdev and kbd. Regards, Marvin Raaijmakers On Tue, Apr 28, 2009 at 2:31 AM, Peter Hutterer wrote: > On Mon, Apr 27, 2009 at 09:15:22PM +0200, Marvin Raaijmakers wrote: >> Is there a way to detect, from the host that runs the X clients, what >> keyboard driver is used by the X server? I want to know this because I >> want to write a program that should behave differently when the evdev >> driver is used instead of the traditional keyboard driver. > > Not really, but you can query the keyboards for all properties. If a bunch of > evdev properties are present, then it's probably running the kbd driver. > > May I ask what the actual problem is you're trying to solve? > > Cheers, > Peter > ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Xserver 1.6.0 problem?
Dear All: I now use Xserver 1.6.0, set Disable in Monitor Section Section "Monitor" Identifier "" ... Option "Disable" Option "PreferredMode" "1024x768" EndSection The device still light on, does it reasonable? If anyone know something about it , give me some advice. Thanks a lot ! ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Griffin Powermate evdev setup
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? The old driver was ugly (bitmasks etc) but useful. I hope the new version hasn't "thrown the baby out with the bath water". > 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 Event: time 1240909109.357837, -- Report Sync Event: time 1240909109.445820, type 2 (Relative), code 7 (Dial), value -1 Event: time 1240909109.445837, -- Report Sync Event: time 1240909109.509826, type 2 (Relative), code 7 (Dial), value -1 Event: time 1240909109.509843, -- Report Sync Event: time 1240909109.565820, type 2 (Relative), code 7 (Dial), value -1 Event: time 1240909109.565836, -- Report Sync Event: time 1240909109.629825, type 2 (Relative), code 7 (Dial), value -1 Event: time 1240909109.629841, -- Report Sync Event: time 1240909110.213829, type 2 (Relative), code 7 (Dial), value 1 Event: time 1240909110.213844, -- Report Sync Event: time 1240909110.253823, type 2 (Relative), code 7 (Dial), value 1 Event: time 1240909110.253839, -- Report Sync Event: time 1240909110.309823, type 2 (Relative), code 7 (Dial), value 1 Event: time 1240909110.309839, -- Report Sync Event: time 1240909110.381825, type 2 (Relative), code 7 (Dial), value 1 Event: time 1240909110.381842, -- Report Sync Event: time 1240909110.485828, type 2 (Relative), code 7 (Dial), value 1 Event: time 1240909110.485845, -- Report Sync Event: time 1240909110.573827, type 2 (Relative), code 7 (Dial), value 1 Event: time 1240909110.573842, -- Report Sync Event: time 1240909110.653830, type 2 (Relative), code 7 (Dial), value 1 Event: time 1240909110.653847, -- Report Sync Event: time 1240909112.125830, type 1 (Key), code 256 (Btn0), value 1 Event: time 1240909112.125847, -- Report Sync Event: time 1240909112.381823, type 1 (Key), code 256 (Btn0), value 0 Event: time 1240909112.381838, -- Report Sync Event: time 1240909112.789830, type 2 (Relative), code 7 (Dial), value 1 Event: time 1240909112.789845, -- Report Sync Event: time 1240909112.893831, type 1 (Key), code 256 (Btn0), value 1 Event: time 1240909112.893848, -- Report Sync Event: time 1240909113.141823, type 1 (Key), code 256 (Btn0), value 0 Event: time 1240909113.141838, -- Report Sync Thanks, Phil. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Griffin Powermate evdev setup
On Tuesday 28 April 2009, Phil Endecott 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? > >The old driver was ugly (bitmasks etc) but useful. I hope the new >version hasn't "thrown the baby out with the bath water". > If they have, there are going to be some unhappy folks who run milling machines with the griffin and find them at least as handy as bottled beer. >> 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 >Event: time 1240909109.357837, -- Report Sync >Event: time 1240909109.445820, type 2 (Relative), code 7 (Dial), value -1 >Event: time 1240909109.445837, -- Report Sync >Event: time 1240909109.509826, type 2 (Relative), code 7 (Dial), value -1 >Event: time 1240909109.509843, -- Report Sync >Event: time 1240909109.565820, type 2 (Relative), code 7 (Dial), value -1 >Event: time 1240909109.565836, -- Report Sync >Event: time 1240909109.629825, type 2 (Relative), code 7 (Dial), value -1 >Event: time 1240909109.629841, -- Report Sync >Event: time 1240909110.213829, type 2 (Relative), code 7 (Dial), value 1 >Event: time 1240909110.213844, -- Report Sync >Event: time 1240909110.253823, type 2 (Relative), code 7 (Dial), value 1 >Event: time 1240909110.253839, -- Report Sync >Event: time 1240909110.309823, type 2 (Relative), code 7 (Dial), value 1 >Event: time 1240909110.309839, -- Report Sync >Event: time 1240909110.381825, type 2 (Relative), code 7 (Dial), value 1 >Event: time 1240909110.381842, -- Report Sync >Event: time 1240909110.485828, type 2 (Relative), code 7 (Dial), value 1 >Event: time 1240909110.485845, -- Report Sync >Event: time 1240909110.573827, type 2 (Relative), code 7 (Dial), value 1 >Event: time 1240909110.573842, -- Report Sync >Event: time 1240909110.653830, type 2 (Relative), code 7 (Dial), value 1 >Event: time 1240909110.653847, -- Report Sync >Event: time 1240909112.125830, type 1 (Key), code 256 (Btn0), value 1 >Event: time 1240909112.125847, -- Report Sync >Event: time 1240909112.381823, type 1 (Key), code 256 (Btn0), value 0 >Event: time 1240909112.381838, -- Report Sync >Event: time 1240909112.789830, type 2 (Relative), code 7 (Dial), value 1 >Event: time 1240909112.789845, -- Report Sync >Event: time 1240909112.893831, type 1 (Key), code 256 (Btn0), value 1 >Event: time 1240909112.893848, -- Report Sync >Event: time 1240909113.141823, type 1 (Key), code 256 (Btn0), value 0 >Event: time 1240909113.141838, -- Report Sync > > >Thanks, Phil. > > > >___ >xorg mailing list >xorg@lists.freedesktop.org >http://lists.freedesktop.org/mailman/listinfo/xorg -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Fine day for friends. So-so day for you. ___
Re: Griffin Powermate evdev setup
On Tue, Apr 28, 2009 at 2:33 AM, Phil Endecott 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 wrote: On Tue, Apr 28, 2009 at 2:33 AM, Phil Endecott 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.) 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. Cheers, Phil. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: After an update I get error message "no screens found"
On Mon, Apr 27, 2009 at 13:02:41 +0200, rosenrei...@arcor.de wrote: > Hi, > I updated my system and after a reboot the Xserver failed to start. I got the > message: > > (EE) Screen(s) found, but none have a usable configuration. > Fatal server error: > no screens found > > I tried the new unmodified xorg.conf and my old working xorg.conf (attached) > configuration and I got the same error (logfile attached). > > What's wrong? > > My system is debian lenny-testing, 2.6.26-1-sparc64, X.Org X Server 1.4.2 > The X pci stuff is busted on sparc in lenny. You'll have to either use a framebuffer driver, or upgrade to unstable. Cheers, Julien ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Griffin Powermate evdev setup
On Tue, Apr 28, 2009 at 8:00 AM, Phil Endecott wrote: > Dan Nicholson wrote: >> >> On Tue, Apr 28, 2009 at 2:33 AM, Phil Endecott >> 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: Xorg and multiple graphics cards
also sprach Alex Deucher [2009.04.21.1734 +0200]:
> Looks like an XAA problem. Can you try with EXA?
> Option "AccelMethod" "EXA"
> in your device sections.
I tried with EXA in all four sections, and the result I get is
another segfault:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7f611512d790 (LWP 16444)]
dixLookupPrivate (privates=0x2739540, key=0x0) at ../../dix/privates.c:79
79 ../../dix/privates.c: No such file or directory.
in ../../dix/privates.c
#0 dixLookupPrivate (privates=0x2739540, key=0x0) at ../../dix/privates.c:79
ptr =
#1 0x004b31c0 in xf86RandR12CreateScreenResources (pScreen=0x27392b0)
at ../../../../hw/xfree86/modes/xf86RandR12.c:756
pScrn = (ScrnInfoPtr) 0x2701440
c =
width =
height =
mmWidth =
mmHeight =
#2 0x004ab87f in xf86CrtcCreateScreenResources (screen=0x27392b0)
at ../../../../hw/xfree86/modes/xf86Crtc.c:701
No locals.
#3 0x00433014 in main (argc=4, argv=0x7fff1d14e6d8,
envp=) at ../../dix/main.c:325
pScreen = (ScreenPtr) 0x27392b0
i = 0
alwaysCheckForInput = {0, 1}
Backtrace:
0: /usr/bin/Xorg(xorg_backtrace+0x26) [0x4ef016]
1: /usr/bin/Xorg(xf86SigHandler+0x39) [0x476509]
2: /lib/libc.so.6 [0x7f6112bd71a0]
3: /usr/bin/Xorg(dixLookupPrivate+0x4) [0x433bd4]
4: /usr/bin/Xorg(xf86RandR12CreateScreenResources+0x50) [0x4b31c0]
5: /usr/bin/Xorg [0x4ab87f]
6: /usr/bin/Xorg(main+0x264) [0x433014]
7: /lib/libc.so.6(__libc_start_main+0xe6) [0x7f6112bc35a6]
8: /usr/bin/Xorg [0x4325f9]
Log and xorg.conf attached.
--
martin | http://madduck.net/ | http://two.sentenc.es/
"i never travel without my diary. one should always have something
sensational to read on the train."
-- oscar wilde
spamtraps: madduck.bo...@madduck.net
Xorg.1.log.bz2
Description: Binary data
# /etc/X11/xorg.conf (xorg X Window System server configuration file)
#
# This file was generated by dexconf, the Debian X Configuration tool, using
# values from the debconf database.
#
# Edit this file with caution, and see the /etc/X11/xorg.conf manual page.
# (Type "man /etc/X11/xorg.conf" at the shell prompt.)
#
# This file is automatically updated on xserver-xorg package upgrades *only*
# if it has not been modified since the last upgrade of the xserver-xorg
# package.
#
# If you have edited this file but would like it to be automatically updated
# again, run the following commands:
#
# cp /etc/X11/xorg.conf /etc/X11/xorg.conf.custom
# sudo sh -c 'md5sum /etc/X11/xorg.conf >/var/lib/xfree86/xorg.conf.md5sum'
# sudo dpkg-reconfigure xserver-xorg
### begin triple-head config
Section "ServerLayout"
Identifier"Triple Head"
Screen 0"Screen[0]"
Screen 1"Screen[1]" RightOf "Screen[0]"
Screen 2"Screen[2]" RightOf "Screen[1]"
InputDevice "Generic Keyboard"
InputDevice "Configured Mouse"
InputDevice "Wacom stylus" "SendCoreEvents"
InputDevice "Wacom eraser" "SendCoreEvents"
InputDevice "Wacom cursor" "SendCoreEvents"
Option "Clone" "off"
Option "Xinerama" "yes"
EndSection
#Section "Files"
# ModulePath"/usr/local/lib/xorg/modules,/usr/lib/xorg/modules"
#EndSection
Section "Module"
Load "wacom"
EndSection
Section "ServerFlags"
Option "DontZap" "yes"
Option "AllowDeactivateGrabs" "yes"
Option "AllowClosedownGrabs" "yes"
EndSection
Section "Device"
Identifier "Radeon 9250[0]"
Driver "radeon"
BusID "PCI:0:12:0"
Screen 0
# Option "HW Cursor" "off"
# Option "MergedFB" "true"
Option "MergedFB" "off"
Option "AccelMethod" "EXA"
EndSection
Section "Device"
Identifier "Radeon 9250[1]"
Driver "radeon"
BusID "PCI:0:12:1"
Screen 1
# Option "HW Cursor" "off"
# Option "MergedFB" "true"
Option "MergedFB" "off"
Option "AccelMethod" "EXA"
EndSection
Section "Device"
Identifier "Radeon 9200[0]"
Driver "radeon"
BusID "PCI:1:0:0"
Screen 0
# Option "MergedFB" "true"
# Option "MonitorLayout" "TMDS, CRT"
# Option "CRT2Position" "RightOf"
# Option "MetaModes" "1280x1024-1280x1024 1152x864-1152x864
1024x768-1024x768 800x600-800x600 640x480-640x480"
Option "MergedFB" "off"
Option "AccelMethod" "EXA"
EndSection
Section "Device"
Identifier "Radeon 9200[1]"
Driver "radeon"
BusID "PCI:1:0:0"
Screen 1
# Option "MergedFB" "true"
# Option "MonitorLayout" "TMDS, CRT"
# Option "CRT2Position" "RightOf"
# Option "MetaModes" "1280x1024-1280x1024 1152x864-1152x864
1024x768-1024x768 800x600-800x600 640x480-640x480"
Option "MergedFB" "off"
Option "AccelMethod" "EXA"
EndSection
Section "Monitor"
Identifier "MRM B18XA"
HorizS
Forwarding Single X Window to Multiple Displays
Hello, I am investigating the possibility of forwarding the display of an X-Window to more than one destination. I know that the DISPLAY environment variable can be set to forward the display/control of a window to another location. Is it possible to forward a single display to more than one destination, one being the master with control, and the other a slave (display-only) display? We are building a networked aircraft crew trainer where each station is a single machine. There are modes of operation where more than one crew station needs to see a shared common display. I was hoping to run a single instance of the shared application on a server and forward the display to multiple destinations. Is this possible with the X.Org X Window system? Can the DISPLAY environment variable handle multiple arguments? Thanks in advance, Rick Smith Research Software Engineer Alion Science and Technology BMH Operation ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Forwarding Single X Window to Multiple Displays
X toolkits can easily be used to drive multiple displays at the same time (presuming your connections are allowed in the first place, which it would be in your application). - Jim On Tue, 2009-04-28 at 12:48 -0400, Smith, Richard G wrote: > Hello, > > > > I am investigating the possibility of forwarding the display of an > X-Window to more than one destination. I know that the DISPLAY > environment variable can be set to forward the display/control of a > window to another location. Is it possible to forward a single display > to more than one destination, one being the master with control, and > the other a slave (display-only) display? We are building a networked > aircraft crew trainer where each station is a single machine. There > are modes of operation where more than one crew station needs to see a > shared common display. I was hoping to run a single instance of the > shared application on a server and forward the display to multiple > destinations. > > > > Is this possible with the X.Org X Window system? Can the DISPLAY > environment variable handle multiple arguments? > > > > Thanks in advance, > > Rick Smith > > Research Software Engineer > > Alion Science and Technology > > BMH Operation > > > ___ > xorg mailing list > xorg@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/xorg -- Jim Gettys ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: 2.6.30-rc2 + xorg-intel-2.7.0 + DRM_I915_KMS = corruption
On Tue, 28 Apr 2009 06:37:10 +0100 Alex Bennee wrote: > 2009/4/27 Florian Mickler : > > On Sun, 19 Apr 2009 07:27:35 +0100 > > Alex Bennee wrote: > > > >> Heading the warnings in the menuconfig I did try and ensure I have > >> all the up to date parts of user-space. With KMS enabled GDM > >> starts up but then corrupts the display with vertical lines. > >> Disabling the kernel config and everything starts up fine, UXA > >> acceleration seems OK and the speed of compiz is finally back up > >> to ~60fps thanks to the A17 fix. > >> > >> Am I missing another bit of user space for KMS to work properly? > > Apparently I was missing a key bit and had to enable fbdev from the > command line: > > kernel /kernel-2.6-drm root=/dev/sda2 > video=intelfb:mode=1440x900...@75,accel,hwcursor > > However I still saw the same corruption kick in when GDM started. I > couldn't switch mode either which kinda defeated the point. The above seems to indicate that you have some FB drivers built into your kernel; that will likely fail in weird ways. Try disabling all the FB drivers, but keep CONFIG_FRAMEBUFFER_CONSOLE enabled. Then when you load the i915 driver you should get a nice console. -- Jesse Barnes, Intel Open Source Technology Center ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [radeon] Dual-Head, second display stays black
On Mon, Apr 27, 2009 at 9:56 PM, Andreas Juch wrote: > Hi! > > I have a Xserver 1.6.1 and the radeon release 6.12.2 here. I have two > screens connected to the two DVI outputs of a RHD 3470 card. The 22" > display works fine, the 17" display stays black (monitor's OSD says "no > signal found"). According to xrandr everything _should_ be fine: > > Screen 0: minimum 320 x 200, current 2960 x 1050, maximum 2960 x 1050 > DVI-1 connected 1280x1024+1680+0 (normal left inverted right x axis y axis) > 338mm x 270mm > 1280x1024 60.0*+ 75.0 72.0 60.0* > 1152x864 75.0 > 1024x768 75.0 70.1 60.0 > 832x624 74.6 > 800x600 72.2 75.0 60.3 > 640x480 75.0 72.8 66.7 59.9 > 720x400 70.1 > 640x350 70.1 > DVI-0 connected 1680x1050+0+0 (normal left inverted right x axis y axis) > 474mm x 296mm > 1680x1050 59.9*+ > 1280x1024 75.0 60.0 > 1440x900 75.0 59.9 > 1280x960 60.0 > 1280x800 74.9 59.9 > 1152x864 75.0 > 1152x720 60.0 > 1024x768 75.0 60.0 > 832x624 74.6 > 800x600 75.0 60.3 > 640x480 75.0 59.9 > 720x400 70.1 > > I pasted the Xorg.log to http://pastebin.ca/1405612 . I got these two > screens to work with radeonhd and fglrx, is there a chance to get that > working with radeon too? Should work. Does: sleep 5; xset dpms force off cause both screens to come back on when you move the mouse? If so, can you try with the radeon driver from git? Alex ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Xorg and multiple graphics cards
also sprach martin f krafft [2009.04.28.1806 +0200]: > I tried with EXA in all four sections, and the result I get is > another segfault: Julien pointed me to commit faf7dfa099f5b42a703313fbd1bf8afdad07a179, which seems to solve that problem. Unfortunately, like the hydra, this gave way to more problems. Remember I have a dual-card triple-head Zaphod setup, so the heads are 0-0, 0-1, and 1-0, where the latter is the first and only head on the second card. Both cards are Radeon 9200: 00:0c.1 Display controller: ATI Technologies Inc RV280 [Radeon 9200 PRO] (Secondary) (rev 01) 01:00.0 VGA compatible controller: ATI Technologies Inc RV280 [Radeon 9200] (rev 01) 1. The 1-0 head has plenty of weird pixelation errors, making fonts only barely readable 2. X (as well as console-setup on tty) seem to believe the screens are taller and place the bottom edge below the physical edge, meaning I cannot see the bottom centimetre or so. Auto-adjust does not fix this on any of the heds. 3. When moving the mouse from head to head, the "old" pointer is left on the edge of the head we just left, and stays there while a "new" pointer moves about on the entered head. When moving back, the "new" pointer stays at the edge, and the "old" pointer is resumed. 4. Switching to tty1 causes screen corruption and the tty is actually never displayed. Switching to X on :0 (I used :1 to test) restores heads 0-0 and 1-0, but head 0-1 stays black -- until I reboot. It feels like progress, but it's not where I need to be yet... I now have a good feeling of the software and can easily test commits, so if you have anything... Cheers, -- martin | http://madduck.net/ | http://two.sentenc.es/ plan to be spontaneous tomorrow. spamtraps: madduck.bo...@madduck.net digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/) ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Xorg and multiple graphics cards
On Tue, Apr 28, 2009 at 1:47 PM, martin f krafft wrote: > also sprach martin f krafft [2009.04.28.1806 +0200]: >> I tried with EXA in all four sections, and the result I get is >> another segfault: > > Julien pointed me to commit > faf7dfa099f5b42a703313fbd1bf8afdad07a179, which seems to solve that > problem. > > Unfortunately, like the hydra, this gave way to more problems. > Remember I have a dual-card triple-head Zaphod setup, so the heads > are 0-0, 0-1, and 1-0, where the latter is the first and only head > on the second card. Both cards are Radeon 9200: > > 00:0c.1 Display controller: ATI Technologies Inc RV280 [Radeon 9200 PRO] > (Secondary) (rev 01) > 01:00.0 VGA compatible controller: ATI Technologies Inc RV280 [Radeon 9200] > (rev 01) > > 1. The 1-0 head has plenty of weird pixelation errors, making fonts > only barely readable > > 2. X (as well as console-setup on tty) seem to believe the screens > are taller and place the bottom edge below the physical edge, > meaning I cannot see the bottom centimetre or so. Auto-adjust > does not fix this on any of the heds. > > 3. When moving the mouse from head to head, the "old" pointer is > left on the edge of the head we just left, and stays there while > a "new" pointer moves about on the entered head. When moving > back, the "new" pointer stays at the edge, and the "old" pointer > is resumed. > > 4. Switching to tty1 causes screen corruption and the tty is > actually never displayed. Switching to X on :0 (I used :1 to > test) restores heads 0-0 and 1-0, but head 0-1 stays black -- > until I reboot. > > It feels like progress, but it's not where I need to be yet... > > I now have a good feeling of the software and can easily test > commits, so if you have anything... It won't work until your secondary card is posted. Int10 posting of secondary cards doesn't work with libpciaccess. The non-int10 post code in the ddx is incomplete and disabled. You can try it with the attached patch, but it likely won't make a difference. Your best bet short term is to use xserver 1.4.x. Alex legacy_init.diff Description: application/mbox ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Forwarding Single X Window to Multiple Displays
Smith, Richard G wrote: > Is it possible to forward a single display > to more than one destination, one being the master with control, and the > other a slave (display-only) display? I have been considering a similar problem. In my case, the easiest solution appears to be VNC: http://www.karlrunge.com/x11vnc/ With x11vnc, it is easy to set up an application on a single display, and then forward the content of that display to arbitrarily many "view-only" watchers. --Ben signature.asc Description: OpenPGP digital signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [radeon] Dual-Head, second display stays black
Am Tue, 28 Apr 2009 13:46:08 -0400 schrieb Alex Deucher : > On Mon, Apr 27, 2009 at 9:56 PM, Andreas Juch wrote: > > Hi! > > > > I have a Xserver 1.6.1 and the radeon release 6.12.2 here. I have > > two screens connected to the two DVI outputs of a RHD 3470 card. > > The 22" display works fine, the 17" display stays black (monitor's > > OSD says "no signal found"). According to xrandr everything > > _should_ be fine: > > > > Screen 0: minimum 320 x 200, current 2960 x 1050, maximum 2960 x > > 1050 DVI-1 connected 1280x1024+1680+0 (normal left inverted right x > > axis y axis) 338mm x 270mm 1280x1024 60.0*+ 75.0 72.0 > > 60.0* 1152x864 75.0 > > 1024x768 75.0 70.1 60.0 > > 832x624 74.6 > > 800x600 72.2 75.0 60.3 > > 640x480 75.0 72.8 66.7 59.9 > > 720x400 70.1 > > 640x350 70.1 > > DVI-0 connected 1680x1050+0+0 (normal left inverted right x axis y > > axis) 474mm x 296mm 1680x1050 59.9*+ > > 1280x1024 75.0 60.0 > > 1440x900 75.0 59.9 > > 1280x960 60.0 > > 1280x800 74.9 59.9 > > 1152x864 75.0 > > 1152x720 60.0 > > 1024x768 75.0 60.0 > > 832x624 74.6 > > 800x600 75.0 60.3 > > 640x480 75.0 59.9 > > 720x400 70.1 > > > > I pasted the Xorg.log to http://pastebin.ca/1405612 . I got these > > two screens to work with radeonhd and fglrx, is there a chance to > > get that working with radeon too? > > Should work. Does: > sleep 5; xset dpms force off > cause both screens to come back on when you move the mouse? No, that doesn't work, only the display that worked before works after that. > If so, can you try with the radeon driver from git? I tried it anyway (want to try the powermanagement), no change here. I pasted the Xorg.log to http://pastebin.ca/1406415 if you need that. Anything else I can try? I tried to disable the "working" display and only use the "blank" one, but that doesn't turn on the blank monitor on, but uses the resolution of the blank monitor on the working monitor. I used that xorg.conf for doing this: > [... Keyboard, Mouse, DontZap Server Flag ...] > > Section "Device" > Identifier "Configured Video Device" > Driver "radeon" > Option "monitor-DVI-1" "17Zoll" > #Option "monitor-DVI-0" "22Zoll" > #Option "DefaultConnectorTable" "true" > EndSection > > #Section "Monitor" > # Identifier "22Zoll" > # Option "PreferredMode" "1680x1050" > #EndSection > > Section "Monitor" > Identifier "17Zoll" > Option "PreferredMode" "1280x1024" > #Option "RightOf" "22Zoll" > EndSection > > Section "Screen" > Identifier "Default Screen" > #Monitor"22Zoll" > Monitor "17Zoll" > Device "Configured Video Device" > SubSection "Display" > Virtual 2960 1050 > EndSubSection > EndSection I hope you have an idea what's wrong here. The radeon driver is really great except my problem. Video playback works very well with kernel 2.6.30-rc3, thanks a lot for that! Best regards, Andreas > > Alex > ___ > 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
How to detect remote login
Can somebody think of a way to execute a command when a user logs in and out remotely via XDMCP? The use case is like this: Several X sessions are running on PC A for different users. They have Firefox and Thunderbird running. A user wants to log in via XDMCP from PC B (X server) to their account on PC A. Firefox and Thunderbird are started when the session is restored. Now Firefox and Thunderbird can't have more than one instance running. So I need to find a way to get a notification when a the remote session starts, and then execute a kill command for the local Firefox and Thunderbird instances. Firefox and Thunderbird should be started locally again after the remote session has ended. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Xorg and multiple graphics cards
also sprach Alex Deucher [2009.04.28.1957 +0200]: > It won't work until your secondary card is posted. Int10 posting > of secondary cards doesn't work with libpciaccess. The non-int10 > post code in the ddx is incomplete and disabled. You also explained on IRC: Normally when you boot, the system bios initializes your video card by executing a routine in the video bios. That's what we call posting. So in your case, the non-int10 post code in the ddx needs to be fixed, or we need to make int10 stuff work for seconday cards with libpciaccess. > You can try it with the attached patch, but it likely won't make > a difference. It didn't. :( > Your best bet short term is to use xserver 1.4.x. Any idea how long that "short term" is? 1.4.x works fine for me at the moment, but I'd rather not build on that basis for indeterminate time... -- martin | http://madduck.net/ | http://two.sentenc.es/ "our destiny exercises its influence over us even when, as yet, we have not learned its nature; it is our future that lays down the law of our today." - friedrich nietzsche spamtraps: madduck.bo...@madduck.net digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/) ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Xorg and multiple graphics cards
On Tue, Apr 28, 2009 at 3:07 PM, martin f krafft wrote: > also sprach Alex Deucher [2009.04.28.1957 +0200]: >> It won't work until your secondary card is posted. Int10 posting >> of secondary cards doesn't work with libpciaccess. The non-int10 >> post code in the ddx is incomplete and disabled. > > You also explained on IRC: > > Normally when you boot, the system bios initializes your video > card by executing a routine in the video bios. That's what we call > posting. So in your case, the non-int10 post code in the ddx needs > to be fixed, or we need to make int10 stuff work for seconday > cards with libpciaccess. > >> You can try it with the attached patch, but it likely won't make >> a difference. > > It didn't. :( > >> Your best bet short term is to use xserver 1.4.x. > > Any idea how long that "short term" is? 1.4.x works fine for me at > the moment, but I'd rather not build on that basis for indeterminate > time... Hard to say, depends on when the work gets done. The universal fix would be to get int10 and vga stuff working with libpciaccess, which on Linux at least, requires a kernel vga arbiter. Not sure about other OSs. radeon specific fixes would be to fix the non-int10 post code in the radeon driver or switch to the kms/mm enabled radeon drm and fix up any multi-card issues that may be lurking there. Alex ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Xorg and multiple graphics cards
also sprach Alex Deucher [2009.04.28.2122 +0200]: > Hard to say, depends on when the work gets done. The universal > fix would be to get int10 and vga stuff working with libpciaccess, > which on Linux at least, requires a kernel vga arbiter. Not sure > about other OSs. radeon specific fixes would be to fix the > non-int10 post code in the radeon driver or switch to the kms/mm > enabled radeon drm and fix up any multi-card issues that may be > lurking there. Let me know if I can help, even though I better stay away from actual code or hardware. -- martin | http://madduck.net/ | http://two.sentenc.es/ "it usually takes more than three weeks to prepare a good impromptu speech. -- mark twain spamtraps: madduck.bo...@madduck.net digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/) ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
AllowEmptyInput and HAL
Hello again, My efforts to recover from a dead computer continue. I have resurrected the old disk in a new box, but the new box has a different graphics chip and installing the (Debian packaged) driver for that has brought in new bits of everything, and it has all gone bad. Specifically, when X started I had no keyboard or mouse. After power-cycling [no other way to escape!] I found a message in the log saying that "AllowEmptyInput" was enabled and that my keyboard and mouse configuration was being ignored. Having looked this up in man xorg.conf I see that this mode is the default. I'll try to be polite: This does not seem like the most useful behaviour. Having set AutoAddDevices to false in order to disable the unhelpful AllowEmptyInput, I now have a functioning mouse. But I have a keyboard where every alternate keystroke produces the right letter and the others produce garbage (maybe top-bit-set characters?). I also noticed some messages in the log where "config/hal" complained that "NewInputDeviceRequest failed". Presumably this is because of my AutoAddDevices. I had noticed that Debian installed "hal"; I had not previously heard of it. It looks like something that sits on top of udev. So I've now spent most of three days on this. I just want a computer that works, preferably as well as the old one did, and while I don't have one I can't do much work [I'm self-employed]. So could someone please suggest what I should do: - Is there some simple set of xorg.conf settings that will make it just work like it did before, without any AllowEmptyInput and HAL stuff and with a functional keyboard? - Or would I be better off trying to learn how this HAL thing works? X is something that I only have to understand once every few years when I have some new hardware. By the next time I need to understand it, either I have forgotten something vital or it has all changed Cheers, Phil. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[ANNOUNCE] xf86-video-siliconmotion 1.7.1
Alan Coopersmith (2): Remove xorgconfig & xorgcfg from See Also list in man page Add README with pointers to mailing list, bugzilla & git repos Francisco Jerez (8): Dynamically switch virtual refresh mode. Set dualhead to on by default on SM72x chipsets. Minor corrections at the man page. Drop the outdated configuration options documentation in README. Wait for vertical retrace before writing registers at SMILynx_CrtcDPMS_* Don't attempt monitor detection on SM712. Increase the maximum clock value to 200MHz on SM712. Bump version to 1.7.1. Jamie Lentin (1): Stop clearing of "VESA compliance power down mode" bit Matthieu Herrb (1): Fix direct access to IO space on chipsets with no IOBase mapping. Niels de Vos (1): siliconmotion: Fix disabling of debugging if SMI501_CLI_DEBUG is set to 0 git tag: xf86-video-siliconmotion-1.7.1 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-siliconmotion-1.7.1.tar.bz2 MD5: 744e5e68caaa545ac7e8523f74fc6579 xf86-video-siliconmotion-1.7.1.tar.bz2 SHA1: d246ee7ca3e70ddcd7fcff92d4d0174abef0c241 xf86-video-siliconmotion-1.7.1.tar.bz2 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-siliconmotion-1.7.1.tar.gz MD5: 6d02829ac77673cbb2044b04dbd43bc7 xf86-video-siliconmotion-1.7.1.tar.gz SHA1: d7ce4ef13f3f29fd8db95e7b09ba1a08091a9ef3 xf86-video-siliconmotion-1.7.1.tar.gz pgp4RBoymDlWE.pgp Description: PGP signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: AllowEmptyInput and HAL
Am Dienstag, den 28.04.2009, 22:01 +0100 schrieb Phil Endecott: > Hello again, > > My efforts to recover from a dead computer continue. I have > resurrected the old disk in a new box, but the new box has a different > graphics chip and installing the (Debian packaged) driver for that has > brought in new bits of everything, and it has all gone bad. > > Specifically, when X started I had no keyboard or mouse. After > power-cycling [no other way to escape!] I found a message in the log > saying that "AllowEmptyInput" was enabled and that my keyboard and > mouse configuration was being ignored. Having looked this up in man > xorg.conf I see that this mode is the default. I'll try to be polite: > This does not seem like the most useful behaviour. > > Having set AutoAddDevices to false in order to disable the unhelpful > AllowEmptyInput, I now have a functioning mouse. But I have a keyboard > where every alternate keystroke produces the right letter and the > others produce garbage (maybe top-bit-set characters?). > > I also noticed some messages in the log where "config/hal" complained > that "NewInputDeviceRequest failed". Presumably this is because of my > AutoAddDevices. I had noticed that Debian installed "hal"; I had not > previously heard of it. It looks like something that sits on top of udev. > > So I've now spent most of three days on this. I just want a computer > that works, preferably as well as the old one did, and while I don't > have one I can't do much work [I'm self-employed]. So could someone > please suggest what I should do: > > - Is there some simple set of xorg.conf settings that will make it just > work like it did before, without any AllowEmptyInput and HAL stuff and > with a functional keyboard? > > - Or would I be better off trying to learn how this HAL thing works? > > X is something that I only have to understand once every few years when > I have some new hardware. By the next time I need to understand it, > either I have forgotten something vital or it has all changed What Debian release do you use and what X.org version? If you run unstable with xserver-xorg 1:7.4+1 you should be able to just delete your xorg.conf file and everything should work out of the box. Thanks, Paul signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Detecting the used keyboard driver
On Tue, Apr 28, 2009 at 11:10:57AM +0200, Marvin Raaijmakers wrote: > Well I developed keyTouch, a program that allows the user to bind > actions to extra function keys (like the Play/Pause, WWW or Zoom keys > for example) on a keyboard. KeyTouch is a collection of programs. One > program binds a key's scancode to a Linux keycode. So it changes the > mapping inside the Linux kernel. Another program is an X client and > grabs all key events of the extra function keys. So this program needs > to know the X keycodes of the keys and thus it will have to translate > the kernel keycode to the X keycode. These translations are different > when the evdev input driver is used by the X server instead of the kbd > driver. This sounds like the X client is doing the wrong thing. It should get the mapping from the server and then bind to the correct keysym. The only thing a keycode tells you is that it is the e.g. 5th key in the second row. And even that you have to guess. > What do you mean by "query the keyboards for all properties"? Using > XListInputDevices? Then there need to be different values for > min_keycode, max_keycode or num_keys (or am I wrong?). These are > however the same for evdev and kbd. XListDeviceProperties() Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Forwarding Single X Window to Multiple Displays
On Tue, Apr 28, 2009 at 12:48:04PM -0400, Smith, Richard G wrote: > I am investigating the possibility of forwarding the display of an > X-Window to more than one destination. I know that the DISPLAY > environment variable can be set to forward the display/control of a > window to another location. Is it possible to forward a single display > to more than one destination, one being the master with control, and the > other a slave (display-only) display? We are building a networked > aircraft crew trainer where each station is a single machine. There are > modes of operation where more than one crew station needs to see a > shared common display. I was hoping to run a single instance of the > shared application on a server and forward the display to multiple > destinations. It's easy to write an app that displays the same window on multiple displays at once. All you need is multiple XOpenDisplay() calls and then you just treat both windows like two completely separate windows (which means you handle redrawing on both separately, etc.). It's not easy at all however replicates the output on another display without that application's support. There's many details in the protocol that make this task hard and you're likely to run into a wall at some point where you just can't get further with reasonable effort. Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Old System, New Install Isuue
Hello!
Fedora Core 4 (Linux 2.6.17-1)
yum install xorg-x11 (v.6.8.2)
This is a "headless" dedicated system with FC4 pre-installed by the
hosting service. It is one of hundreds in a remote rack. I have no
direct access to the system.
I have been running and updating this system using the CLI for about 3
years, however I now need some sort of X system running if I want to run
VisualChat software for my users. Its Java programming requires a
windows manager (X) when run on a Linux box.
Since I had no X installed on this system, I used yum to install it,
seemingly without any issues. All of the dependencies (i.e. xinit) were
successfully installed, as well.
After installing xorg-x11, I ran "X -configure" to generate a
system-specific config file. I am now stuck with the server failing to
start and generating no error messages that I can act upon.
Executing 'X -config /user/xorg.conf.new', I see this midway through the
Xorg.0.log file:
Xorg.0.log snippet start ==
(II) I810(0): Display Info: CRT: attached: FALSE, present: FALSE, \
size: (0,0)
...
(II) I810(0): Currently active displays on Pipe A:
(II) I810(0): CRT
(==) I810(0): Display is using Pipe A
...
(II) I810(0): Will use BIOS call 0x5f05 to set refresh rates for CRTs.
log end ==
And then this at the end of the log (when everything halts):
Xorg.0.log snippet start ==
...
(WW) I810(0): Successfully set original devices
(WW) I810(0): Setting the original video mode instead of restoring \
the saved state
(WW) I810(0): Extended BIOS function 0x5f05 failed.
(II) I810(0): BIOS call 0x5f05 not supported, setting refresh with \
VBE 3 method.
(II) I810(0): xf86UnbindGARTMemory: unbind key 7
...
{unbind key 0,1,3,2,4,5,6 follow}
...
(WW) I810(0): Successfully set original devices (2)
log end ==
boom. It gets no further.
So a BIOS failure to call 0x5f05 would seem to indicate a problem
getting the (non-existent) monitor to initialize.
Is it possible to run X without an attached monitor, mouse or keyboard?
Shall I post the full Xorg.0.log and my xorg.conf.new file?
I appreciate any guidance.
James
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Old System, New Install Isuue
James Butler wrote: > Is it possible to run X without an attached monitor, mouse or keyboard? Yes - Xvfb or Xvnc are the easiest ways. Xorg using the "dummy" video driver and "void" input driver is also a possibility. -- -Alan Coopersmith- alan.coopersm...@sun.com Sun Microsystems, Inc. - X Window System Engineering ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Old System, New Install Isuue
Alan Coopersmith wrote: > James Butler wrote: >> Is it possible to run X without an attached monitor, mouse or keyboard? > > Yes - Xvfb or Xvnc are the easiest ways. Xorg using the "dummy" video > driver and "void" input driver is also a possibility. > Thank you! Xfb sounds like it would work for me. Basically I need something that will run continuously in the background (daemon-like), rather than during a VNC session. I'll get started on compiling from source to test it out. Where would I find the "dummy" or "void" driver options to try before I reinstall everything? James ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Old System, New Install Isuue
James Butler wrote: > Alan Coopersmith wrote: >> James Butler wrote: >>> Is it possible to run X without an attached monitor, mouse or keyboard? >> Yes - Xvfb or Xvnc are the easiest ways. Xorg using the "dummy" video >> driver and "void" input driver is also a possibility. >> > Thank you! > > Xfb sounds like it would work for me. Basically I need something that will > run continuously in the background (daemon-like), rather than during a VNC > session. I'll get started on compiling from source to test it out. > > Where would I find the "dummy" or "void" driver options to try before I > reinstall everything? The Xorg source packages are xf86-video-dummy and xf86-input-void - from a quick google, it looks like the Fedora RPM names for these are xorg-x11-drv-dummy and xorg-x11-drv-void. -- -Alan Coopersmith- alan.coopersm...@sun.com Sun Microsystems, Inc. - X Window System Engineering ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: AllowEmptyInput and HAL
Hi, On Tue, Apr 28, 2009 at 10:01:25PM +0100, Phil Endecott wrote: > Specifically, when X started I had no keyboard or mouse. After > power-cycling [no other way to escape!] I found a message in the log > saying that "AllowEmptyInput" was enabled and that my keyboard and > mouse configuration was being ignored. Having looked this up in man > xorg.conf I see that this mode is the default. I'll try to be polite: > This does not seem like the most useful behaviour. AllowEmptyInput does not mean that your keyboard and mouse configuration is being ignored; conversely, it means that it's not a fatal error to have no keyboard and mouse configuration whatsoever. So if AEI changes anything, you don't have a keyboard and mouse configured. > Having set AutoAddDevices to false in order to disable the unhelpful > AllowEmptyInput, I now have a functioning mouse. But I have a keyboard > where every alternate keystroke produces the right letter and the > others produce garbage (maybe top-bit-set characters?). Cool. Could you please send xev output? > I also noticed some messages in the log where "config/hal" complained > that "NewInputDeviceRequest failed". Presumably this is because of my > AutoAddDevices. I had noticed that Debian installed "hal"; I had not > previously heard of it. It looks like something that sits on top of udev. Yes, it is. NewInputDeviceRequest failing sounds like the evdev driver isn't installed. BTW, attaching complete logs instead of two-word snippets often leads to significantly more happiness. > So I've now spent most of three days on this. I just want a computer > that works, preferably as well as the old one did, and while I don't > have one I can't do much work [I'm self-employed]. So could someone > please suggest what I should do: > > - Is there some simple set of xorg.conf settings that will make it just > work like it did before, without any AllowEmptyInput and HAL stuff and > with a functional keyboard? The Debian guys can explain that much better than me. > - Or would I be better off trying to learn how this HAL thing works? > > X is something that I only have to understand once every few years when > I have some new hardware. By the next time I need to understand it, > either I have forgotten something vital or it has all changed Well, not upgrading guarantees there won't be any changes. :) Cheers, Daniel signature.asc Description: Digital signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: AllowEmptyInput and HAL
On Tue, 28 Apr 2009, Phil Endecott wrote: > Hello again, > > My efforts to recover from a dead computer continue. I have > resurrected the old disk in a new box, but the new box has a different > graphics chip and installing the (Debian packaged) driver for that has > brought in new bits of everything, and it has all gone bad. > > Specifically, when X started I had no keyboard or mouse. After > power-cycling [no other way to escape!] I found a message in the log > saying that "AllowEmptyInput" was enabled and that my keyboard and > mouse configuration was being ignored. Having looked this up in man > xorg.conf I see that this mode is the default. I'll try to be polite: > This does not seem like the most useful behaviour. > > Having set AutoAddDevices to false in order to disable the unhelpful > AllowEmptyInput, I now have a functioning mouse. But I have a keyboard > where every alternate keystroke produces the right letter and the > others produce garbage (maybe top-bit-set characters?). > > I also noticed some messages in the log where "config/hal" complained > that "NewInputDeviceRequest failed". Presumably this is because of my > AutoAddDevices. I had noticed that Debian installed "hal"; I had not > previously heard of it. It looks like something that sits on top of udev. > > So I've now spent most of three days on this. I just want a computer > that works, preferably as well as the old one did, and while I don't > have one I can't do much work [I'm self-employed]. So could someone > please suggest what I should do: > > - Is there some simple set of xorg.conf settings that will make it just > work like it did before, without any AllowEmptyInput and HAL stuff and > with a functional keyboard? > > - Or would I be better off trying to learn how this HAL thing works? > > X is something that I only have to understand once every few years when > I have some new hardware. By the next time I need to understand it, > either I have forgotten something vital or it has all changed > Here's how I would have done it: Take new box with new drive and install an operating system of your choice. Make sure it works the way you want it to. Now install old drive as 2nd drive and mount it at /mnt/hd Pick and choose files to copy from old to new. Hope this helps, Russ ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Sluggish 2D with radeon Xpress 200M
On 27 Apr 2009, Damien Mir told this: > How can I see more precisely what eats CPU inside the Xorg process ? If you have debugging symbols installed for your X server (they tend to be a separate package) the GNOME 'sysprof' tool will do the magic for you, and is pretty much idiot-proof (it took me a few seconds to figure out how to use it, and I never did work out how to use oprofile). (It includes a kernel module you have to compile and install.) It's a system-wide profiler, but if X really is eating machine time, it should be near the top of the list. (It shows what functions inside each process eat time, on a process-by-process basis, most expensive processes first.) ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[ANNOUNCE] xf86-input-citron 2.2.2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alan Coopersmith (4): Remove xorgconfig & xorgcfg from See Also list in man page Add README with pointers to mailing list, bugzilla & git repos Delete duplicate EXTRA_DIST line from Makefile Version 2.2.2 Paulo Cesar Pereira de Andrade (2): Don't call xf86SoundKbdBell and xf86XInputSetSendCoreEvents Janitor: correct make distcheck. Peter Hutterer (2): Check for XINPUT ABI 3. Fix build, XF86_VERSION_CURRENT doesn't exist anymore. git tag: xf86-input-citron-2.2.2 http://xorg.freedesktop.org/archive/individual/driver/xf86-input-citron-2.2.2.tar.bz2 MD5: 8cad35da16ea4688ebb74533ccc7f190 SHA1: 4c001399724f4d019aabb0450a251f209db25cd2 http://xorg.freedesktop.org/archive/individual/driver/xf86-input-citron-2.2.2.tar.gz MD5: 976f815b1f46ce063a66fba508b64340 SHA1: 42e51b70733f7ffa479d3b6b4fab5f8a1ecf9ebf - -- -Alan Coopersmith- alan.coopersm...@sun.com Sun Microsystems, Inc. - X Window System Engineering -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (SunOS) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkn3p5MACgkQovueCB8tEw55FACfYrAnoHEqP1JG+5xTloxaIjbv rDIAn333sjMjEqMUc2bLkwDgIHJNjHYh =SEXp -END PGP SIGNATURE- ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Xorg and multiple graphics cards
Hi, martin f krafft escreveu: > 3. When moving the mouse from head to head, the "old" pointer is >left on the edge of the head we just left, and stays there while >a "new" pointer moves about on the entered head. When moving >back, the "new" pointer stays at the edge, and the "old" pointer >is resumed. Yeah, I saw it here as well. But this is usually easy to fix. Find which commit caused the bug with a binary search in the tree (man git-bisect). I'd guess something inside mipointer.c Cheers, Tiago ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Xorg and multiple graphics cards
Alex Deucher escreveu: > On Tue, Apr 28, 2009 at 3:07 PM, martin f krafft wrote: >>> Your best bet short term is to use xserver 1.4.x. >> Any idea how long that "short term" is? 1.4.x works fine for me at >> the moment, but I'd rather not build on that basis for indeterminate >> time... > > Hard to say, depends on when the work gets done. The universal fix > would be to get int10 and vga stuff working with libpciaccess, which > on Linux at least, requires a kernel vga arbiter. Not sure about > other OSs. radeon specific fixes would be to fix the non-int10 post > code in the radeon driver or switch to the kms/mm enabled radeon drm > and fix up any multi-card issues that may be lurking there. Yeah, I'm trying to solve part of this. Martin, if you want to help in some way, test this patch and see if it works, please: http://lists.x.org/archives/xorg-devel/2009-April/000794.html Thank you, Tiago ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[ANNOUNCE] xf86-video-intel: 2.7.99.1 snapshot (now with 10% reduced fat!)
This is a development snapshot very early in the process toward developing 2.8. There have been some big changes to the code, and we're anxious to get feedback on these changes as early as possible. Here is a summary of the biggest changes: * Driver now depends on X server 1.6 or later * Eliminate XAA and EXA support (in favor of UXA) * Eliminate DRI1 support * Fixes for running without DRI at all These code removals represent a deletion of a substantial amount of code, (and hopefully piles of bugs), as well as reduce the maintenance effort going forward as the number of combinatorial configurations for the driver are greatly reduced. This means that users are much more likely to be running code that has actually been tested, and it will be much easy for developers to replicate bugs that users experience. Many thanks to Eric Anholt for gutting so much code! And see Keith Packard's writeup describing the benefits of this code removal: http://keithp.com/blogs/Sharpening_the_Intel_Driver_Focus/ One of the things that would be most useful in testing this release is to revisit any outstanding bugs that you have previously reported. If the buggy behavior is gone, (or the bug is no longer relevant---such as a bug that's specific to XAA only), please feel free to indicate so in bugzilla or even just close the bug. If you confirm that the bug is still present, please indicate so in the bug report. (I was going to ask that you select a 1.7.99 version, but it looks like bugzilla only has versions for products not compoenents, while we use a "xorg" product and a "driver/intel" component.) We definitely want to make any such confirmed bugs a priority, so it would be nice to have a consistent mechanism to search for these bugs. Suggestions are welcome on the best approach. Thanks in advance for any testing or feedback on this snapshot. -Carl Getting the snapshot git tag: 2.7.99.1 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-intel-2.7.99.1.tar.bz2 MD5: ec222b8e617f79c3dee03db71db053a2 xf86-video-intel-2.7.99.1.tar.bz2 SHA1: c8c88d341dd79c4561018c5a279c8f6e66f84089 xf86-video-intel-2.7.99.1.tar.bz2 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-intel-2.7.99.1.tar.gz MD5: 797eaa5d8abdabd92bdc261ca1b53634 xf86-video-intel-2.7.99.1.tar.gz SHA1: 5ee985ed22e483ac470cceaa65866a871370b747 xf86-video-intel-2.7.99.1.tar.gz All commits since 2.7.0 --- [Note that many of these commits were already cherry-picked and present in 2.7.0] Alan Coopersmith (1): Fix UXA to build with Sun compilers (use __func__ instead of __FUNCTION__) Albert Damen (2): Non-GEM allocations incorrectly force TILE_NONE (bug 20797) Fix crash with XV with large virtual display Carl Worth (18): Revert the rest of the EXA_VERSION_MAJOR bump Use WAIT_FOR_SCAN_LINE instead of WAIT_FOR_VBLANK Remove support for 'auto'(-1) value of XV_SYNC_TO_VBLANK Fix new video sync-to-blank code for multi-head Don't clip video to CRTC in the case of textured video Add a RELEASING file documenting the release process README: Remove almost all time-sensitive information Add a new AUTHORS file Clarify that the default acceleration is UXA if KMS is available. Add a NEWS files with release-notes for 2.7.0 Add AUTHORS and NEWS to EXTRA_DIST NEWS: Add note about broken PAT code in some kernels RELEASING: Update instructions to reflect some minor process improvements AUTHORS: Add Robert Lowery to the authors file README: Fix typos in chipset list, and point to how_to_report_bug web page RELEASING: Note that --with-xserver-source is needed for make distcheck Increment version to 2.7.99.1 NEWS: Add notes for 2.7.99.1 snapshot Dan Nicholson (1): Fix dist of xvmc sources Eric Anholt (35): Fix XV with non-GEM kernels by allocating a larger fake bufmgr. Add PGETBL_CTL to the debug output. Add dumping of 915 and 945 fence registers. Add DCC register dumping. Move contributed m4 (dolt) to a subdirectory so we can include it with others. Add shave support, enabled by default. Remove some dead i830.h struct members. Rename EXA rendering functions to UXA, since we're keeping them post-EXA. Remove dead mono cursor load code. Remove unused i830_output_type_names Use a static inline to replace if (0) to an unused stub function. Staticize a bunch of functions and variables in the driver. Replace a bunch of #ifdef debug flushing/syncing with a single function. Remove dead monitor detect debugger. Remove dead xoffset/yoffset from pre-randr. Revert "fix overflow warning on videoRam" Don't try to do anything for I830Sync when VT switched. Fix drmSetMaster/DropMaster error messages. Don't initialize DRI2 if the fd we get is not master-capable.
Re: Xorg and multiple graphics cards
On Tue, 28 Apr 2009, Tiago Vignatti wrote: > Alex Deucher escreveu: >> On Tue, Apr 28, 2009 at 3:07 PM, martin f krafft wrote: Your best bet short term is to use xserver 1.4.x. >>> Any idea how long that "short term" is? 1.4.x works fine for me at >>> the moment, but I'd rather not build on that basis for indeterminate >>> time... >> >> Hard to say, depends on when the work gets done. The universal fix >> would be to get int10 and vga stuff working with libpciaccess, which >> on Linux at least, requires a kernel vga arbiter. Not sure about >> other OSs. radeon specific fixes would be to fix the non-int10 post >> code in the radeon driver or switch to the kms/mm enabled radeon drm >> and fix up any multi-card issues that may be lurking there. > > Yeah, I'm trying to solve part of this. > > Martin, if you want to help in some way, test this patch and see if it > works, please: > >http://lists.x.org/archives/xorg-devel/2009-April/000794.html Can I point out that https://bugs.freedesktop.org/show_bug.cgi?id=20816 and its dependencies are the appropriate bugs for the issue? Not that I want to discourage mailing list comment, or anything, but merely to point any relevant people at what's already been done, and what hasn't. I'm hoping, sometime within the next month or two, to be temporarily in a position where I can at least do some testing on this; I'll have access to a dual NVidia/SiS system that I can install random stuff on. Thanks all for your time... - | Name: Tim Nelson | Because the Creator is,| | E-mail: wayl...@wayland.id.au| I am | - BEGIN GEEK CODE BLOCK Version 3.12 GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V- PE(+) Y+>++ PGP->+++ R(+) !tv b++ DI D G+ e++> h! y- -END GEEK CODE BLOCK- ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Xorg and multiple graphics cards
Hi Timothy, Timothy S. Nelson escreveu: > Can I point out that > https://bugs.freedesktop.org/show_bug.cgi?id=20816 and its dependencies > are the appropriate bugs for the issue? Not that I want to discourage > mailing list comment, or anything, but merely to point any relevant > people at what's already been done, and what hasn't. Yes, please feed that bug. And if you like to do that, I also have a list here of related bugs :) https://bugs.freedesktop.org/show_bug.cgi?id=18160 https://bugs.freedesktop.org/show_bug.cgi?id=18839 https://bugs.freedesktop.org/show_bug.cgi?id=18321 https://bugs.freedesktop.org/show_bug.cgi?id=20849 https://bugzilla.redhat.com/show_bug.cgi?id=454864 Cheers, Tiago ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Old System, New Install Isuue
On Tuesday 28 April 2009, James Butler wrote:
> Hello!
>
> Fedora Core 4 (Linux 2.6.17-1)
> yum install xorg-x11 (v.6.8.2)
>
> This is a "headless" dedicated system with FC4 pre-installed by the
> hosting service. It is one of hundreds in a remote rack. I have no
> direct access to the system.
>
> I have been running and updating this system using the CLI for about 3
> years, however I now need some sort of X system running if I want to run
> VisualChat software for my users. Its Java programming requires a
> windows manager (X) when run on a Linux box.
>
> Since I had no X installed on this system, I used yum to install it,
> seemingly without any issues. All of the dependencies (i.e. xinit) were
> successfully installed, as well.
>
> After installing xorg-x11, I ran "X -configure" to generate a
> system-specific config file. I am now stuck with the server failing to
> start and generating no error messages that I can act upon.
>
> Executing 'X -config /user/xorg.conf.new', I see this midway through the
> Xorg.0.log file:
>
> Xorg.0.log snippet start ==
> (II) I810(0): Display Info: CRT: attached: FALSE, present: FALSE, \
> size: (0,0)
> ...
> (II) I810(0): Currently active displays on Pipe A:
> (II) I810(0): CRT
> (==) I810(0): Display is using Pipe A
> ...
> (II) I810(0): Will use BIOS call 0x5f05 to set refresh rates for CRTs.
> log end ==
>
> And then this at the end of the log (when everything halts):
>
> Xorg.0.log snippet start ==
> ...
> (WW) I810(0): Successfully set original devices
> (WW) I810(0): Setting the original video mode instead of restoring \
> the saved state
> (WW) I810(0): Extended BIOS function 0x5f05 failed.
> (II) I810(0): BIOS call 0x5f05 not supported, setting refresh with \
> VBE 3 method.
> (II) I810(0): xf86UnbindGARTMemory: unbind key 7
> ...
> {unbind key 0,1,3,2,4,5,6 follow}
> ...
> (WW) I810(0): Successfully set original devices (2)
> log end ==
>
> boom. It gets no further.
>
> So a BIOS failure to call 0x5f05 would seem to indicate a problem
> getting the (non-existent) monitor to initialize.
>
> Is it possible to run X without an attached monitor, mouse or keyboard?
>
> Shall I post the full Xorg.0.log and my xorg.conf.new file?
>
> I appreciate any guidance.
>
> James
Hi James,
depending on the exact needs of the Java software you want to install you
might be able to do it without an X environment at all.
Have you tried running Java in headless mode (java -Djava.awt.headless=true)
as documented on
http://java.sun.com/developer/technicalArticles/J2SE/Desktop/headless/ ? I
presume that you only need a graphical environment during installation and
that the software is later used over the web. Some installers I've seen fall
back to character output when run in headless mode.
HTH,
Magnus
signature.asc
Description: This is a digitally signed message part.
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
