Menu
▾
▴
linuxconsole-dev
|
From: <han...@sa...> - 2005-08-06 11:33:41
|
Hi! I have 1 NVIDIA Gefore FX 5200 PCI, and one NVIDIA Gefore 6600 PCI-E card. I have both X servers set up correctly so that they run without any problem seperatly (with different keyboards and mice). Both X servers use the nvidia close source 6629 driver. My problem is that whenever I try to start the second X server, while the first one is already running, the monitor connected to the first X server goes black (monitor is turned off/signal lost). The xserver itself however continues running, and all applications (like music from xmms) also continue running. There are no errors in any log files. There is no difference when trying to start the X servers in the opposite order. Starting the second X server always kills the display of the one already running. I have tried to turn the monitor back on with "xset dpms dorce on -display :0.0", but this doesn't help. I'm running x.org 6.8.2 with the IsloateDevice patch. I'm actually not running ruby anymore, but I'm using the evdev driver for the separate keyboards/mice (https://bugs.freedesktop.org/show_bug.cgi?id=968), so in a sence I'm posting to the "wrong" list, but I guess people here are the most experienced with these kind of setups. The PCI card is also set as the primary graphics card in bios, otherwise it didn't work at all. Thanks for any help on this! -Hans |
|
From: <ce...@ri...> - 2005-08-07 00:11:03
|
han...@sa... a =E9crit : > I have 1 NVIDIA Gefore FX 5200 PCI, and one NVIDIA Gefore 6600 PCI-E=20 > card. I have both X servers set up correctly so that they run without=20 > any problem seperatly (with different keyboards and mice). Both X=20 > servers use the nvidia close source 6629 driver. >=20 > My problem is that whenever I try to start the second X server, while=20 > the first one is already running, the monitor connected to the first X=20 > server goes black (monitor is turned off/signal lost). The xserver=20 > itself however continues running, and all applications (like music from= =20 > xmms) also continue running. There are no errors in any log files. Ther= e=20 > is no difference when trying to start the X servers in the opposite=20 > order. Starting the second X server always kills the display of the one= =20 > already running. Your problem looks similar to the one encountered with radeon cards. Except you state that the first display is turned off without vga signal. A Radeon card keeps the VGA signal up but the display is black=20 and can be restored by video mode switching (Ctrl-Alt-+/-). In your case, without VGA signal, it shouldn't be possible to restore the display but you could check just in case. As explained in my previous mail, the problem occurs when the second card do VGA IOs at initialization. Regarding the open source driver those functions are provided by the vgahw module (see http://www.x.org/X11R6.8.2/doc/DESIGN19.html for details). The log=20 entries are shown below: (II) Loading sub module "vgahw" (II) LoadModule: "vgahw" (II) Loading /usr/X11R6/lib/modules/libvgahw.a (II) Module vgahw: vendor=3D"X.Org Foundation" compiled for 6.8.2, module version =3D 0.1.0 ABI class: X.Org Video Driver, version 0.7 (II) RADEON(0): vgaHWGetIOBase: hwp->IOBase is 0x03d0, hwp->PIOOffset is=20 0x0000 I don't know if the close source nvidia driver uses this module or access the VGA registers by itself. Anyway the only solution is to modify the driver to disable VGA IOs. This has been done with the "VGAAccess" option for radeon and rage128=20 drivers in the following patches posted in the xorg bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=3D2064 https://bugs.freedesktop.org/show_bug.cgi?id=3D2089 Regarding nvidia, you might ask them to implement this feature in their driver. Regards, C=E9dric |
|
From: Arne G. G. <ar...@li...> - 2005-08-10 07:43:32
|
* han...@sa... > Hi! > > I have 1 NVIDIA Gefore FX 5200 PCI, and one NVIDIA Gefore 6600 PCI-E > card. I have both X servers set up correctly so that they run without > any problem seperatly (with different keyboards and mice). Both X > servers use the nvidia close source 6629 driver. I am running two Nvidia cards (two FX5200, AGP and PCI) with the closed source driver from Nvidia without problems. I'm currently using the 7667/amd64 version, but I've been running with these two cards for some time now. (They used to sit in a standard x86-box.) I'm using the stock Ubuntu X.org (or, rather, I used to do so; I've had to recompile it to not ignore key 103 when using the evdev keyboard driver). Are you using the -sharevts option when running the second X server? Arne. |
|
From: Andrej v. d. Z. <ma...@ya...> - 2005-08-21 21:17:02
|
Hi, I am having the same problem with the two NVidia cards GeForce4 MX4000 AGP 8x and GeForce FX5200 PCI on Debian unstable with Ruby patched kernel 2.6.12. I am using the NVidia driver version 7676. I read somewhere that I should use the -sharevts option when starting the second X server. I tried, but this option is not recognized. How should I do this? Thanks a bunch! Andrej --- han...@sa... wrote: > > Hi! > > I have 1 NVIDIA Gefore FX 5200 PCI, and one NVIDIA > Gefore 6600 PCI-E > card. I have both X servers set up correctly so that > they run without > any problem seperatly (with different keyboards and > mice). Both X > servers use the nvidia close source 6629 driver. > > My problem is that whenever I try to start the > second X server, while > the first one is already running, the monitor > connected to the first X > server goes black (monitor is turned off/signal > lost). The xserver > itself however continues running, and all > applications (like music from > xmms) also continue running. There are no errors in > any log files. There > is no difference when trying to start the X servers > in the opposite > order. Starting the second X server always kills the > display of the one > already running. > > I have tried to turn the monitor back on with "xset > dpms dorce on > -display :0.0", but this doesn't help. > > I'm running x.org 6.8.2 with the IsloateDevice > patch. I'm actually not > running ruby anymore, but I'm using the evdev driver > for the separate > keyboards/mice > (https://bugs.freedesktop.org/show_bug.cgi?id=968), > so in > a sence I'm posting to the "wrong" list, but I guess > people here are the > most experienced with these kind of setups. > > The PCI card is also set as the primary graphics > card in bios, otherwise > it didn't work at all. > > Thanks for any help on this! > > -Hans > > > > ------------------------------------------------------- > SF.Net email is Sponsored by the Better Software > Conference & EXPO > September 19-22, 2005 * San Francisco, CA * > Development Lifecycle Practices > Agile & Plan-Driven Development * Managing Projects > & Teams * Testing & QA > Security * Process Improvement & Measurement * > http://www.sqe.com/bsce5sf > _______________________________________________ > Linuxconsole-dev mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxconsole-dev > ___________________________________________________________ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com |
|
From: Aivils S. <ai...@un...> - 2005-08-22 07:17:44
Attachments:
faketty-0.01.tar.bz2
|
Hi , All! Don't like patched kernel. Ok try out vanilla! Main goal of this fake TTY driver is multi seat Linux box creation without any patch under Debian stable or Mandriva 2005 LE , which distros contains -isolateDevice patch of X. Recent Linux kernel does not force us use evdev or tty layer. Even sytem operator can load new input handler. Actualy i write faketty kernel module, which create device file for each keyboard. That device file emulate TTY layer. Keypress events are translated to standard TTY layer keycodes. These keycodes can use X for input. linux-ruby assign /dev/ttyXX for each keyboard. faketty assign /dev/fttyXX for each keyboard. Current i use simple starting method # modprobe faketty # rm -f /dev/tty5[0-9] # ln -s /dev/ftty0 /dev/tty50 Now /dev/tty50 is not standard TTY layer device but new. Start X via new layer: # startx -- vt50 LIMITATIONS: All pluged in keybords must be opened via new faketty driver, because each keyboard at normal TTY steer LED's of all keyboards of system. If You will start multiple X, every one X must use faketty for correct work of LED's. This mean text mode console is unavaible. BUGS: faketty creates /dev/fttyXX files for each input device, but must create for keyboards only. file attached to mail. Aivils Stoss |
|
From: Hugo V. <hvw...@ya...> - 2005-08-22 10:59:28
|
--- Aivils Stoss <ai...@un...> wrote: > Hi , All! > > Don't like patched kernel. Ok try out vanilla! <snip> > > > LIMITATIONS: > > All pluged in keybords must be opened via new > faketty driver, because > each keyboard at normal TTY steer LED's of all > keyboards of system. If You > will > start multiple X, every one X must use faketty for > correct work of LED's. This > mean text mode console is unavaible. > Boooo!!! :-( H __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com |
|
From: Aivils S. <ai...@un...> - 2005-08-22 12:01:41
|
On Pirmdiena, 22. Augusts 2005 13:59, Hugo Vanwoerkom wrote: > > LIMITATIONS: > > > > =A0=A0=A0=A0=A0=A0All pluged in keybords must be opened via new > > faketty driver, because > > each keyboard at normal TTY steer LED's of all > > keyboards of system. If You > > will > > start multiple X, every one X must use faketty for > > correct work of LED's. This > > mean text mode console is unavaible. > > Boooo!!! =A0:-( Google: KERNEL FUNCTION HIJACKING and replace kbd_bh kernelspace func :-) Aivils |
|
From: Aivils S. <ai...@un...> - 2005-08-24 06:30:37
|
On Pirmdiena, 22. Augusts 2005 13:59, Hugo Vanwoerkom wrote: > > Hi , All! > > > > Don't like patched kernel. Ok try out vanilla! > > <snip> > > > LIMITATIONS: > > > > =A0=A0=A0=A0=A0=A0All pluged in keybords must be opened via new > > faketty driver, because > > each keyboard at normal TTY steer LED's of all > > keyboards of system. If You > > will > > start multiple X, every one X must use faketty for > > correct work of LED's. This > > mean text mode console is unavaible. > > Boooo!!! =A0:-( http://www.ltn.lv/~aivils/files/hijackled-2.6.11-12mdk.tar.bz2 hijacled kernel module is prepared for 2.6.11-12mdk kernel runtime modification. It replaces keyboard LED steering function with another proper one. After loading of hijackled into kernel use is new LED function. After module unload old function comes back. At normal kernel any keyboard steer LED's of all keyboards without any state cheking. New function does not touch already grabed input devices. With new function ungrabed keyboard steer all ungrabed keyboard LED's, grabed keyboard steer only his own LED's. This feature is neccessary for faketty kernel module. INSTALL: # make # make install # modprobe hijacled If You will use this module under another kernel, please replace hj_kbd_handler hj_keyboard_tasklet hj_ledstate hj_kbd_table addresses, which can be found in /boot/System.map Unfortunately i do not know which kernel is true under Mandriva 2005 LE Both modules, faketty and hijackled, i can load and set up my system without reboot. Non x86 platform status is unknown. Aivils Stoss |
|
From: Helge H. <hel...@ai...> - 2005-08-24 09:06:00
|
Aivils Stoss wrote: >Hi , All! > >Don't like patched kernel. Ok try out vanilla! > > Main goal of this fake TTY driver is multi seat Linux box creation >without any patch under Debian stable or Mandriva 2005 LE , which distros >contains -isolateDevice patch of X. > > Recent Linux kernel does not force us use evdev or tty layer. Even sytem >operator can load new input handler. Actualy i write faketty kernel module, >which create device file for each keyboard. That device file emulate TTY >layer. > > Interesting. Do this have an advantage compared to using evdev, which is supported in ubuntu's x.org? (this x.org also works on debian testing, making multiseat X possible with a standard kernel. But of course only one user gets a vga console. >Keypress events are translated to standard TTY layer keycodes. These keycodes >can use X for input. > > Is it possible to run a getty taking input from such a faketty, and also redirecting the output of that getty to some process who renders it on a framebuffer device? That'd allow a terminal to appear when X dies for some reason. Even on the second screen. . . Helge Hafting |
|
From: Aivils S. <ai...@un...> - 2005-08-25 06:48:28
|
On Tre=C5=A1diena, 24. Augusts 2005 12:13, Helge Hafting wrote: > >Hi , All! > > > >Don't like patched kernel. Ok try out vanilla! > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Main goal of this fake TTY dri= ver is multi seat Linux box creation > >without any patch under Debian stable or Mandriva 2005 LE , which distros > >contains -isolateDevice patch of X. > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Recent Linux kernel does not f= orce us use evdev or tty layer. Even > > sytem operator can load new input handler. Actualy i write faketty kern= el > > module, which create device file for each keyboard. That device file > > emulate TTY layer. > > =C2=A0 > > Interesting. =C2=A0Do this have an advantage compared to using > evdev, which is supported in ubuntu's x.org? (this x.org > also works on debian testing, making multiseat X possible > with a standard kernel. =C2=A0 No advantage. I need _running_ system with minimum costs. Linux-ruby dummy console is very close to be "fake" tty. Most of dummy console device ioctl's is meaningless. 99% of linux-ruby users start multiple X neither multiple text mode consoles. Why i should create huge patch under these conditions ? > But of course only one user=20 > gets a vga console. A small bug of keyboard_tasklet allow "normal" keyboard steer all LED's of all keyboards. > >Keypress events are translated to standard TTY layer keycodes. These > > keycodes can use X for input. > > =C2=A0 > > Is it possible to run a getty taking input from such a faketty, and > also redirecting the output of that getty to some process who > renders it on a framebuffer device? No. K_XLATE keyboard mode erased during code optimisation. Aivils Stoss |
|
From: Hugo V. <hvw...@ya...> - 2005-08-30 10:22:00
|
--- Aivils Stoss <ai...@un...> wrote: > Hi , All! > > Don't like patched kernel. Ok try out vanilla! > In trying this out on vanilla 2.6.11 the installs went more or less OK given some differences between linux versions. But the start of faketty gives no messages. Those ftty[0-9] have to be allocated because they don't exist. In Debian you use a script for that. What is their major, minor, owner, group, mode? I tried 4, 50, root, tty, 0600 but I think that may the reason for my problem. Result is that either VT50 is shown on monitor1 OR VT51 on monitor2 but not both. Hijacled gave a message: hijacled ON, so must be OK. Hugo __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com |
|
From: Aivils S. <ai...@un...> - 2005-08-30 11:04:12
|
On Otrdiena, 30. Augusts 2005 13:21, Hugo Vanwoerkom wrote: > --- Aivils Stoss <ai...@un...> wrote: > > Hi , All! > > > > Don't like patched kernel. Ok try out vanilla! > > In trying this out on vanilla 2.6.11 the installs went > more or less OK given some differences between linux > versions. > > But the start of faketty gives no messages. Those > ftty[0-9] have to be allocated because they don't > exist. Seems i should add some message. i forgot . > > In Debian you use a script for that. What is their > major, minor, owner, group, mode? major is INPUT_MAJOR == 13 minor is FTTY_MINOR_BASE == 128 crw-rw---- 1 root root 13, 128 aug 30 13:54 /dev/ftty0 owner, group, mode depends from hobbyhorse of system operator i use udev . In this case turn up /dev/ftty0 instead /dev/input/ftty0 under devfs. > I tried 4, 50, root, tty, 0600 but I think that may > the reason for my problem. > > Result is that either VT50 is shown on monitor1 OR > VT51 on monitor2 but not both. > Hijacled gave a message: hijacled ON, so must be OK. at load it is ON. at remove it is OFF. it is removable. Aivils Stoss |
|
From: Hugo V. <hvw...@ya...> - 2005-08-30 16:39:39
|
--- Aivils Stoss <ai...@un...> wrote: > On Otrdiena, 30. Augusts 2005 13:21, Hugo Vanwoerkom > wrote: > > --- Aivils Stoss <ai...@un...> wrote: > > > Hi , All! > > > > > > Don't like patched kernel. Ok try out vanilla! > > > > In trying this out on vanilla 2.6.11 the installs > went > > more or less OK given some differences between > linux > > versions. > > > > But the start of faketty gives no messages. Those > > ftty[0-9] have to be allocated because they don't > > exist. > > Seems i should add some message. i forgot . > > major is INPUT_MAJOR == 13 > minor is FTTY_MINOR_BASE == 128 > crw-rw---- 1 root root 13, 128 aug 30 13:54 > /dev/ftty0 > owner, group, mode depends from hobbyhorse of system > operator > Does the trick. But the keyboards are backwards. I.e. the one in front of monitor1 works on monitor2 and vv. The mice work correctly. I changed /etc/hotplug/kbd.conf (vanilla Debian now) but that seemed to have no effect. cat /proc/bus/input/devices shows: /Tue Aug 30-10:49:48HDA8# cat /proc/bus/input/devices I: Bus=0011 Vendor=0001 Product=0002 Version=ab83 N: Name="AT Raw Set 2 keyboard" P: Phys=isa0060/serio1/input0 H: Handlers=kbd event0 ftty0 B: EV=120013 B: KEY=4 2000000 3802078 f840d001 f2ffffdf ffefffff ffffffff fffffffe B: MSC=10 B: LED=7 I: Bus=0011 Vendor=0001 Product=0001 Version=ab41 N: Name="AT Translated Set 2 keyboard" P: Phys=isa0060/serio0/input0 H: Handlers=kbd event1 ftty1 B: EV=120013 B: KEY=4 2000000 3802078 f840d001 f2ffffdf ffefffff ffffffff fffffffe B: MSC=10 B: LED=7 Also the mouse on monitor1 (=TNT2 AGP with Nvidia driver and evdev protocol) traces garbage. The mouse on monitor 2 does not (=MX-440 PCI) Looks like an elegant solution. H __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com |
|
From: Aivils S. <ai...@un...> - 2005-08-31 10:43:14
|
On Otrdiena, 30. Augusts 2005 19:39, Hugo Vanwoerkom wrote: > --- Aivils Stoss <ai...@un...> wrote: > > On Otrdiena, 30. Augusts 2005 13:21, Hugo Vanwoerkom > > > > wrote: > > > --- Aivils Stoss <ai...@un...> wrote: > > > > Hi , All! > > > > > > > > Don't like patched kernel. Ok try out vanilla! > > > > > > In trying this out on vanilla 2.6.11 the installs > > > > went > > > > > more or less OK given some differences between > > > > linux > > > > > versions. > > > > > > But the start of faketty gives no messages. Those > > > ftty[0-9] have to be allocated because they don't > > > exist. > > > > Seems i should add some message. i forgot . > > > > major is INPUT_MAJOR == 13 > > minor is FTTY_MINOR_BASE == 128 > > crw-rw---- 1 root root 13, 128 aug 30 13:54 > > /dev/ftty0 > > owner, group, mode depends from hobbyhorse of system > > operator > > Does the trick. > > But the keyboards are backwards. I.e. the one in front > of monitor1 works on monitor2 and vv. The mice work > correctly. faketty.c code is borowed from evdev.c mostly 1:1. I suppose first registered keyboard have ftty0. However You are not forced to use stright links like /dev/tty50 -> /dev/ftty0 Instead create that symbolic link in runtime. In case of udev usage, You can create new udev rule. You can use old best /dev/ttyXX for 1st X server and old best text mode too. > I changed /etc/hotplug/kbd.conf (vanilla Debian now) > but that seemed to have no effect. cat Yes. Just like evdev, faketty have not runtime steering interface. Just like evdev faketty have mess with replugged USB devices. > /proc/bus/input/devices shows: > /Tue Aug 30-10:49:48HDA8# cat /proc/bus/input/devices > > Also the mouse on monitor1 (=TNT2 AGP with Nvidia > driver and evdev protocol) traces garbage. The mouse > on monitor 2 does not (=MX-440 PCI) faketty should not have any influence to another input interfaces like kbd,mouse,event. It register new input handler only. > > Looks like an elegant solution. > Time shows. Aivils |
|
From: Aivils S. <ai...@un...> - 2005-09-01 06:55:44
|
On Otrdiena, 30. Augusts 2005 19:39, Hugo Vanwoerkom wrote:
> > major is INPUT_MAJOR =3D=3D 13
> > minor is FTTY_MINOR_BASE =3D=3D 128
> > crw-rw---- =A01 root root 13, 128 aug 30 13:54
> > /dev/ftty0
> > owner, group, mode depends from hobbyhorse of system
> > operator
>
> Does the trick.
>
> But the keyboards are backwards. I.e. the one in front
> of monitor1 works on monitor2 and vv. The mice work
> correctly.
May be this wraper script helps?
#!/bin/sh -e
#
# Scans /proc/bus/input/devices for the given device physicaly location
# like isa0060.serio0.input0 . Please replace slash "/" with period "."
# Aivils Stoss
# GPL v2 or later applies.
PHYS=3Disa0060.serio1.input0
HANDLER=3Dftty
DEVICE=3D`sed -nre '
/^I:/ {
: gather
N
/\nH:/! b gather
/'"$PHYS"'/ {
s/.*('"$HANDLER"'[0-9]*).*/\\1/p
}
}
' < /proc/bus/input/devices`
echo $DEVICE
rm -f /dev/tty50
ln -s /dev/$DEVICE /dev/tty50
exec X $* vt50
|
|
From: Hugo V. <hvw...@ya...> - 2005-09-01 10:15:52
|
--- Aivils Stoss <ai...@un...> wrote:
> On Otrdiena, 30. Augusts 2005 19:39, Hugo Vanwoerkom
> wrote:
> > > major is INPUT_MAJOR == 13
> > > minor is FTTY_MINOR_BASE == 128
> > > crw-rw---- 1 root root 13, 128 aug 30 13:54
> > > /dev/ftty0
> > > owner, group, mode depends from hobbyhorse of
> system
> > > operator
> >
> > Does the trick.
> >
> > But the keyboards are backwards. I.e. the one in
> front
> > of monitor1 works on monitor2 and vv. The mice
> work
> > correctly.
>
> May be this wraper script helps?
>
> #!/bin/sh -e
> #
> # Scans /proc/bus/input/devices for the given device
> physicaly location
> # like isa0060.serio0.input0 . Please replace slash
> "/" with period "."
> # Aivils Stoss
> # GPL v2 or later applies.
>
> PHYS=isa0060.serio1.input0
>
> HANDLER=ftty
>
> DEVICE=`sed -nre '
> /^I:/ {
> : gather
> N
> /\nH:/! b gather
> /'"$PHYS"'/ {
> s/.*('"$HANDLER"'[0-9]*).*/\\1/p
> }
> }
> ' < /proc/bus/input/devices`
> echo $DEVICE
> rm -f /dev/tty50
> ln -s /dev/$DEVICE /dev/tty50
> exec X $* vt50
>
That's it. Now it works as advertized.
I'll report back again on that garbage on VT50, but it
does not always happen.
To get the bell on secondary monitors we hijack it?
This now ought to be a Debian package, because no
kernel patches needed anymore: I am running with
Debian 2.6.11 now. They rejected my wishlist item to
make Ruby a Debian package a while ago.
Hugo
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
|
|
From: Aivils S. <ai...@un...> - 2005-09-01 11:36:05
|
On Ceturtdiena, 1. Septembris 2005 13:15, Hugo Vanwoerkom wrote: > That's it. Now it works as advertized. > I'll report back again on that garbage on VT50, but it > does not always happen. > > To get the bell on secondary monitors we hijack it? No . I should port code from keyboard.c vt_ioctl.c to faketty.c . PC-speaker and Keyboard-speaker must work via existing input layer. > This now ought to be a Debian package, because no > kernel patches needed anymore: I am running with > Debian 2.6.11 now. They rejected my wishlist item to > make Ruby a Debian package a while ago. Actualy it is a kernel patch. Every loadable module can destroy stability of all Linux. I don't know view point of Debian kernel developers about 3rd party modules. Aivils |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X