Menu
▾
▴
linuxconsole-dev
|
From: Aivils S. <Aiv...@un...> - 2003-12-29 12:28:09
|
>I have two framebuffers and fbcon, and ruby 2.6.0 >vc 1-16 on fb0 seems to work fine. cat /var/log/dmesg | grep Console should show Your VT-VC configuration. "Console ... matrox ... take over ... vc:1-16" "Console ... matrox ... vc:17-32" and similar cat /var/log/dmesg | grep "keyboard\.c" >I tried "echo testing > /dev/tty18" to see if >I got something on fb1. Beter add ay least one agetty on /dev/tty17 in Your inittab. >This crashed. Many pages of oops scrolled by, ending in: Seems all "divide by zero" errors is not cleaned :-( >X runs fine using vt7 and the mga driver. Framebuffer X fails, probably >because of vt17 trouble. Hm. You can add one dummy console. dumbcon=1 Aivils Stoss |
|
From: Aivils S. <Aiv...@un...> - 2004-01-05 09:41:08
|
Long holidays elapse so fast. >On Mon, Dec 29, 2003 at 02:28:32PM +0200, Aivils Stoss wrote: >> >> >I have two framebuffers and fbcon, and ruby 2.6.0 >> >vc 1-16 on fb0 seems to work fine. >> >> cat /var/log/dmesg | grep Console >> should show Your VT-VC configuration. >> "Console ... matrox ... take over ... vc:1-16" >> "Console ... matrox ... vc:17-32" >> and similar >> cat /var/log/dmesg | grep "keyboard\.c" >> >Thanks. > >This is what I have: >Console: Colour VGA+ 80x25 vc:1-16 >Console: mono dummy device 80x25 vc:17-17 You must have more. fbcon initializing add some lines, actualy "take over" , when takes over VGA console, take_over_console() vt.c Secondary matrox_crt2 should come in dmesg to, fbcon_add() fbcon.c. According Your dmesg, fbcon was not initialized. >Is it possible to get 17 connected to the scond framebuffer >instead of a dummy device? Yes. But order is hardcoded first all DUMMY then all FB consoles, seems this must be vice versa. dumbcon=0 1st fb take over VGA and so vc:1-16 2nd fb have vc:17-32 with hardcoded vgacon and fbcon. >Seems there is no 18 then. Trying to use 17 >is almost as bad though - letting an xserver use vt17 >goes into D-state as shown by "ps aux". >So I keep running 2.6.0-test11+ruby, where vt17 works. ? Aivils Stoss |
|
From: Helge H. <hel...@ai...> - 2004-01-05 12:15:19
|
Aivils Stoss wrote: > Long holidays elapse so fast. > > >>On Mon, Dec 29, 2003 at 02:28:32PM +0200, Aivils Stoss wrote: >> >>>>I have two framebuffers and fbcon, and ruby 2.6.0 >>>>vc 1-16 on fb0 seems to work fine. >>> >>>cat /var/log/dmesg | grep Console >>>should show Your VT-VC configuration. >>>"Console ... matrox ... take over ... vc:1-16" >>>"Console ... matrox ... vc:17-32" >>>and similar >>>cat /var/log/dmesg | grep "keyboard\.c" >>> >> >>Thanks. >> >>This is what I have: >>Console: Colour VGA+ 80x25 vc:1-16 >>Console: mono dummy device 80x25 vc:17-17 > > > You must have more. fbcon initializing add some lines, actualy > "take over" , when takes over VGA console, take_over_console() vt.c > Secondary matrox_crt2 should come in dmesg to, fbcon_add() fbcon.c. > > According Your dmesg, fbcon was not initialized. > > >>Is it possible to get 17 connected to the scond framebuffer >>instead of a dummy device? > > > Yes. But order is hardcoded first all DUMMY then all FB consoles, > seems this must be vice versa. dumbcon=0 > 1st fb take over VGA and so vc:1-16 That seems to work, yes. > 2nd fb have vc:17-32 Didn't seem to happen for me. I'll post more dmesg output the next time I get a chance to reboot. So I shouldn't need dumbcon=1 because I have two real framebuffers? Will my second keyboard attach to vc:17-32 ? > with hardcoded vgacon and fbcon. > > >>Seems there is no 18 then. Trying to use 17 >>is almost as bad though - letting an xserver use vt17 >>goes into D-state as shown by "ps aux". >>So I keep running 2.6.0-test11+ruby, where vt17 works. > > ? My problem is that trying to use vt17 like this: /usr/X11R6/bin/X :0 vt17 or like this: openvt -c 17 -f gives me a process in D-state when using 2.6.0+ruby. It doesn't matter wether I compile in fbcon or not. Either approace is fine if I try it with vt5 for example. 2.6.0-test11 + cvs ruby of 30/11 lets me use my second keyboard, if I don't compile in fbcon. The machine boots with vgacon, turns on framebuffers but no fbcon (leaving no useable console) and then starts up two xservers. One using v7 and one using vt17. I use dumbcon=1 to get a working vt17. I can then have two users with independent keyboards, logging into different xservers using xdm. Booting 2.6.0+ruby gives me a working fbcon on /dev/fb0. So I can run gettys and switch consoles. I can also run a xserver on vt7. But running a xserver on vt17 (or even doing a cat /dev/tty17) will leave the process accessing tty17 hung in D-state according do "ps aux", and possibly hang the machine too. Running 2.6.0+ruby without fbcon doesn't help. It crashes in the same way, but of course I don't get to see any output in that case. I haven't succeeded in using the second keyboard for anything but sysrq sequences with 2.6.0+ruby, because of these problems. Another unrelated problem: When accessing bios setup or booting plain linux, only one keyboard is useable. This is the one connected to the ps2 keyboard port. Also, only one of the screens works in these cases. The problem with ruby is that ruby decides that the ps2 keyboard port is the "extra" one connected to vt17, while my other keyboard, connected to the ps2 mouse port gets vc:1-16. Physical setup of two workstations: screen1:fb0 screen2:fb1 kbd1:kbd-port kbd2:mouse-port vc:17 vc:1-16 The problem here is that a console login with ruby uses kbd2 and screen 1. Very impractical because of distance. And I can't just swap the keyboards, because then I get the same problem when running plain linux, selecting kernels in the lilo bootprompt, or changing bios setup. I fixed this for my working X setup by running an xserver on screen1 using vt17 and an xserver on screen2 using vt7. But this breaks in interesting ways with consoles. With consoles only and no X I get the above mentioned problem. If I try to run X too then I get an xserver on screen1 using kbd1 on vc17, while fbconsole using kbd2 on vc1:16 uses the same framebuffer. Clearly not what I want. I want both console and X on the same screen, but with the same keyboard! Again, this _is_ fixable by swapping the keyboard and changing the X setup a bit, but then I get trouble with bios setup and other linux kernels again. The ideal solution is if ruby simply connects the ps2-keyboard-port to vc:1-16 instead of the mouse-port keyboard by default. The second best solution is if I can force this setup with kernel command line parameters somehow. Helge Hafting |
|
From: Aivils S. <Aiv...@un...> - 2004-01-05 15:01:54
|
>>>This is what I have: >>>Console: Colour VGA+ 80x25 vc:1-16 >>>Console: mono dummy device 80x25 vc:17-17 >> >> >> You must have more. fbcon initializing add some lines, actualy >> "take over" , when takes over VGA console, take_over_console() vt.c >> Secondary matrox_crt2 should come in dmesg to, fbcon_add() fbcon.c. >> >> According Your dmesg, fbcon was not initialized. >> >> >>>Is it possible to get 17 connected to the scond framebuffer >>>instead of a dummy device? >> >> >> Yes. But order is hardcoded first all DUMMY then all FB consoles, >> seems this must be vice versa. dumbcon=0 >> 1st fb take over VGA and so vc:1-16 >That seems to work, yes. > >> 2nd fb have vc:17-32 >Didn't seem to happen for me. I'll post more dmesg output >the next time I get a chance to reboot. Can You send to me /var/log/dmesg and System.map files. Looks like matroxfb_crtc2 lacks in Your kernel. >So I shouldn't need dumbcon=1 because I have two real framebuffers? >Will my second keyboard attach to vc:17-32 ? > >> with hardcoded vgacon and fbcon. >> >> >>>Seems there is no 18 then. Trying to use 17 >>>is almost as bad though - letting an xserver use vt17 >>>goes into D-state as shown by "ps aux". >>>So I keep running 2.6.0-test11+ruby, where vt17 works. >> >> ? > >My problem is that trying to use vt17 like this: >/usr/X11R6/bin/X :0 vt17 >or like this: >openvt -c 17 -f > >gives me a process in D-state when using 2.6.0+ruby. >It doesn't matter wether I compile in fbcon or not. >Either approace is fine if I try it with vt5 for example. I'll check it later. >2.6.0-test11 + cvs ruby of 30/11 lets me use >my second keyboard, if I don't compile in fbcon. >The machine boots with vgacon, turns on framebuffers >but no fbcon (leaving no useable console) >and then starts up two xservers. One using v7 and one using vt17. >I use dumbcon=1 to get a working vt17. >I can then have two users with independent keyboards, logging into >different xservers using xdm. > >Booting 2.6.0+ruby gives me a working fbcon on /dev/fb0. >So I can run gettys and switch consoles. I can also run a >xserver on vt7. But running a xserver on vt17 (or even doing >a cat /dev/tty17) will leave the process accessing tty17 hung in >D-state according do "ps aux", and possibly hang the machine too. >Running 2.6.0+ruby without fbcon doesn't help. It crashes in the >same way, but of course I don't get to see any output in that case. > >I haven't succeeded in using the second keyboard for anything but >sysrq sequences with 2.6.0+ruby, because of these problems. > > > > >Another unrelated problem: >When accessing bios setup or booting plain linux, only one keyboard >is useable. This is the one connected to the ps2 keyboard port. >Also, only one of the screens works in these cases. > >The problem with ruby is that ruby decides that the ps2 keyboard port >is the "extra" one connected to vt17, while my other keyboard, connected >to the ps2 mouse port gets vc:1-16. > >Physical setup of two workstations: >screen1:fb0 screen2:fb1 >kbd1:kbd-port kbd2:mouse-port >vc:17 vc:1-16 > >The problem here is that a console login with ruby uses >kbd2 and screen 1. Very impractical because of distance. >And I can't just swap the keyboards, because then I get >the same problem when running plain linux, selecting kernels >in the lilo bootprompt, or changing bios setup. Startting order depends from keyboard model. I use simple lines for my two PS/2 keyboards echo "isa0060/serio0/input0" > /proc/bus/console/00/keyboard echo "isa0060/serio1/input0" > /proc/bus/console/01/keyboard You should put right keyboard physicaly description into right /proc/bus/console/XX/keyboard file. Before write this in Your system startup script , please read /proc/bus/input/devices Correct and wide solution is input.agent usage http://startx.times.lv/mdk/input.agent http://startx.times.lv/mdk/kbd.conf http://startx.times.lv/mdk/mouse.conf http://startx.times.lv/mdk/event.conf http://www.tldp.org/HOWTO/XFree-Local-multi-user-HOWTO/scripts.html Aivils Stoss |
|
From: Helge H. <hel...@ai...> - 2004-01-07 22:25:53
|
Aivils Stoss wrote: >>>>This is what I have: >>>>Console: Colour VGA+ 80x25 vc:1-16 >>>>Console: mono dummy device 80x25 vc:17-17 >>> >>> >>>You must have more. fbcon initializing add some lines, actualy >>>"take over" , when takes over VGA console, take_over_console() vt.c >>>Secondary matrox_crt2 should come in dmesg to, fbcon_add() fbcon.c. >>> >>>According Your dmesg, fbcon was not initialized. [...] Attached: dmesg-ruby260fbc1 which is dmesg for ruby 2.6.0 with matroxfb fbcon and dumbcon=1 dmesg-ruby260fbc2-smart which is dmesg for the same kernel without dumbcon. I hoped the second fbdev would get some vc's, seems it didn't happen. As you see, I get a vc17 with dumbcon. Trying to run an xserver on it fails though. See the attached psaux-ruby260fbc1-xDstate, which shows a stuck X server. The command (/usr/X11R6/bin/X :1 vt17 -xf86config xf86) works when using 2.6.0-test11 and cvs ruby from november 30. 2003. > Can You send to me /var/log/dmesg and System.map files. > Looks like matroxfb_crtc2 lacks in Your kernel. > Isn't that this line? matroxfb_crtc2: secondary head of fb0 was registered as fb1 It doesn't seem to get any vc, not even when I drop the dumbcon. Trying to use X on vt17 when I don't have dumbcon hangs the machine immediately - not even sysrq caused any reaction so I had to use the reset button. Something is wrong when this happen. The vc should ideally work - or give me an ENODEV or similiar. All drivers are compiled into the kernel. [...] >>Another unrelated problem: [...] > Startting order depends from keyboard model. > I use simple lines for my two PS/2 keyboards > > echo "isa0060/serio0/input0" > /proc/bus/console/00/keyboard > echo "isa0060/serio1/input0" > /proc/bus/console/01/keyboard > Thanks, this works. I thought the /proc files were informational only, it didn't occur to me that they were writeable. > You should put right keyboard physicaly description into > right /proc/bus/console/XX/keyboard file. > > Before write this in Your system startup script , please read > /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 B: EV=120003 B: KEY=4 2200000 c061f9 fbc9d621 efdfffdf ffefffff ffffffff fffffffe B: LED=7 I: Bus=0011 Vendor=0001 Product=0002 Version=ab02 N: Name="AT Translated Set 2 keyboard" P: Phys=isa0060/serio0/input0 H: Handlers=kbd event1 B: EV=120003 B: KEY=4 2200000 c061f9 fbc9d621 efdfffdf ffefffff ffffffff fffffffe B: LED=7 Helge Hafting |
|
From: Aivils S. <Aiv...@un...> - 2004-01-08 08:15:06
|
Both ruby-CVS and linus-tree files are unchanged long time, so i can jump from test9 to 2.6.0 without syncing. My sugestion: make mrproper >> Can You send to me /var/log/dmesg and System.map files. >> Looks like matroxfb_crtc2 lacks in Your kernel. >> >Isn't that this line? >matroxfb_crtc2: secondary head of fb0 was registered as fb1 > >It doesn't seem to get any vc, not even when I drop the dumbcon. >Trying to use X on vt17 when I don't have dumbcon hangs the >machine immediately - not even sysrq caused any reaction so I >had to use the reset button. Something is wrong when this happen. >The vc should ideally work - or give me an ENODEV or similiar. > >All drivers are compiled into the kernel. Now i understand. Your dmesg shows: fbcon_startup: mode: MATROX fbcon_startup: visual: 2 fbcon_startup: res: 1280x1024-16 Console: switching to colour MATROX 160x64 vc:1-16 matroxfb_crtc2: secondary head of fb0 was registered as fb1 matroxfb_crtc2 registered after fbcon initialization. This order create gcc when colect module_init(foo_bar) functions. Current ruby fbcon set up console _only_ on registered framebuffer devices. No fbcon event on fb-dev registration. Seems must be regitered additional VT, but that is discutable. Solution: matrox fb-dev compiled into kernel, fbcon as module. Aivils Stoss |
|
From: Helge H. <hel...@ai...> - 2004-01-08 08:38:59
|
Aivils Stoss wrote: > Both ruby-CVS and linus-tree files are unchanged long time, so > i can jump from test9 to 2.6.0 without syncing. > My sugestion: make mrproper Ok, I'll try that. > Now i understand. Your dmesg shows: > fbcon_startup: mode: MATROX > fbcon_startup: visual: 2 > fbcon_startup: res: 1280x1024-16 > Console: switching to colour MATROX 160x64 vc:1-16 > matroxfb_crtc2: secondary head of fb0 was registered as fb1 > > matroxfb_crtc2 registered after fbcon initialization. This order create > gcc when colect module_init(foo_bar) functions. Current ruby fbcon > set up console _only_ on registered framebuffer devices. No fbcon event > on fb-dev registration. Seems must be regitered additional VT, but > that is discutable. > > Solution: matrox fb-dev compiled into kernel, fbcon as module. > I'll try that as a first solution. But shouldn't this secondary head really register a fbdev earlier, such as immediately after registering fb0? Waiting until after fbcon seems wrong to me. Helge Hafting |
|
From: Helge H. <hel...@ai...> - 2004-01-09 20:33:40
|
On Thu, Jan 08, 2004 at 10:11:22AM +0200, Aivils Stoss wrote: > > Both ruby-CVS and linus-tree files are unchanged long time, so > i can jump from test9 to 2.6.0 without syncing. > My sugestion: make mrproper Did that. > matroxfb_crtc2 registered after fbcon initialization. This order create > gcc when colect module_init(foo_bar) functions. Current ruby fbcon > set up console _only_ on registered framebuffer devices. No fbcon event > on fb-dev registration. Seems must be regitered additional VT, but > that is discutable. > > Solution: matrox fb-dev compiled into kernel, fbcon as module. I did that - and it worked! It took some time getting to this point due to some raid-1 trouble. 2.6.0+ruby with modular fbcon came up with two working framebuffer consoles. Two simultaneous xservers, one on each console, works fine. There are some small issues still - switching from X to fbcon on one keyboard also takes the other screen out of graphichs mode. So the fbcons are only useable when not running X - but that is the time I need them most. Helge Hafting |
|
From: Helge H. <hel...@ai...> - 2003-12-30 14:00:15
|
On Mon, Dec 29, 2003 at 02:28:32PM +0200, Aivils Stoss wrote: > > >I have two framebuffers and fbcon, and ruby 2.6.0 > >vc 1-16 on fb0 seems to work fine. > > cat /var/log/dmesg | grep Console > should show Your VT-VC configuration. > "Console ... matrox ... take over ... vc:1-16" > "Console ... matrox ... vc:17-32" > and similar > cat /var/log/dmesg | grep "keyboard\.c" > Thanks. This is what I have: Console: Colour VGA+ 80x25 vc:1-16 Console: mono dummy device 80x25 vc:17-17 Is it possible to get 17 connected to the scond framebuffer instead of a dummy device? Seems there is no 18 then. Trying to use 17 is almost as bad though - letting an xserver use vt17 goes into D-state as shown by "ps aux". So I keep running 2.6.0-test11+ruby, where vt17 works. > >I tried "echo testing > /dev/tty18" to see if > >I got something on fb1. > > Beter add ay least one agetty on /dev/tty17 in > Your inittab. Ideally, I want 6 fbcon terminals + 1 xserver on the second keyboard. In other words, just like two single-user machines. If that isn't possible yet, I want an xserver. > >This crashed. Many pages of oops scrolled by, ending in: > > Seems all "divide by zero" errors is not cleaned :-( > Exactly. It is of course ok to get a ENODEV or similiar if my setup is wrong - it was the oopsing I wanted to report. > >X runs fine using vt7 and the mga driver. Framebuffer X fails, probably > >because of vt17 trouble. > > Hm. You can add one dummy console. dumbcon=1 > dumbcon=1 and two xservers works for 2.6.0-test11+ruby. But not for 2.6.0ruby. Xserver (or openvt -f -c 17) goes into D-state. openvt needs the -f (force) option because it cannot determine wether that vt is in use - a sign of trouble. openvt -c 5 works fine (when no other openvt or getty has claimed that vt of course.) Helge Hafting |
×
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