Menu
▾
▴
linuxconsole-dev
|
From: Hugo V. <hvw...@ya...> - 2004-09-15 23:11:15
|
Hi List!!! With Helge's help I got 2.6.7 + framebuffers +vc's running. Looks great. Have 2 X's running framebuffer vc's also on primary display. However: 2nd X on PCI card shows the login screen but the keyboard doesn't work. (It does on 2.4.x) Dmesg shows this: keyboard: [AT Raw Set 2 keyboard] bound to [dummy device] vc:17-17 keyboard: [AT Translated Set 2 keyboard] bound to [VESA VGA] vc:1-16 Those messages come out of vt_proc.c, which... has Aivils' name on it! Aivils, what am I doing wrong? Why doesn't he say "AT Translated Set 2 keyboard" and VESA VGA for vc:17-17? Thanks! Getting closer! Hugo. _______________________________ Do you Yahoo!? Express yourself with Y! Messenger! Free. Download now. http://messenger.yahoo.com |
|
From: Aivils <ai...@un...> - 2004-09-16 05:29:43
|
On Thursday 16 September 2004 02:11, Hugo Vanwoerkom wrote: > Hi List!!! > > With Helge's help I got 2.6.7 + framebuffers +vc's > running. Looks great. > > Have 2 X's running framebuffer vc's also on primary > display. > > However: 2nd X on PCI card shows the login screen but > the keyboard doesn't work. (It does on 2.4.x) > > Dmesg shows this: > keyboard: [AT Raw Set 2 keyboard] bound to [dummy > device] vc:17-17 > keyboard: [AT Translated Set 2 keyboard] bound to > [VESA VGA] vc:1-16 > > Those messages come out of vt_proc.c, which... > has Aivils' name on it! > Aivils, what am I doing wrong? Why doesn't he say "AT > Translated Set 2 keyboard" and VESA VGA for vc:17-17? VESA VGA fbdev takes over VGA console. Before VGA console uses vc:1-16. See dmesg. Actualy You should use same vt numbers for X starting. Aivils |
|
From: Helge H. <hel...@hi...> - 2004-09-16 08:10:37
|
Hugo Vanwoerkom wrote: >Hi List!!! > >With Helge's help I got 2.6.7 + framebuffers +vc's >running. Looks great. > >Have 2 X's running framebuffer vc's also on primary >display. > >However: 2nd X on PCI card shows the login screen but >the keyboard doesn't work. (It does on 2.4.x) > > You usually have to tell X to use the appropriate vt. If you don't, X grabs the next free vt which is likely bound to the first keyboard. (Std. linux setup runs gettys at vt1 through vt6, and first X on vt7. Another X will then grab vt8, which is bound to the first keyboard. Press ctrl+alt+f8 and the first keyboard brobably works on the second display. This is not what you want. A command line for starting X, taken from /etc/X11/xdm/Xservers: /usr/X11R6/bin/X vt7 -dpi 100 -nolisten tcp -deferglyphs 16 Note the explicit "vt7" in there. Ruby 2.6 allocate vt1 through vt16 to the first keyboard, and vt17 through vt32 to the second. So, specify "vt17" for the second xserver, and it will use the second keyboard. You may also want to specify a different xf86config file, but I guess you already figured that out, considering that X came up at all. Don't specify "vt17" if you're running a getty there, if so, specify vt18 or whatever higher number you have that isn't in use. Note that console switching can be troublesome on the second console, so I recommendrunning only X on it, at least in the beginning. >Dmesg shows this: >keyboard: [AT Raw Set 2 keyboard] bound to [dummy >device] vc:17-17 >keyboard: [AT Translated Set 2 keyboard] bound to >[VESA VGA] vc:1-16 > >Those messages come out of vt_proc.c, which... >has Aivils' name on it! > >Aivils, what am I doing wrong? Why doesn't he say "AT >Translated Set 2 keyboard" and VESA VGA for vc:17-17? > >Thanks! Getting closer! > Are you using a "dumbcon=1" parameter on the kernel command line? That is ok with X, but not with fbcon. (vt17 works either way, but a vt17 bound to dumbcon isn't displayed anywhere. So it is unusable for gettys and other console uses.) If you have two framebuffers, one for each card, then I recommend using framebuffer console and no dumbcon for ruby 2.6.7. "dumbcon=1" is the solution for those without fbcon, because plain vgacon will only grab one keyboard and something (i.e. dumbcon) mus grab the second keyboard and assign VT numbers to it. Helge Hafting |
|
From: Hugo V. <hvw...@ya...> - 2004-09-17 00:28:52
|
Hi! Still have a question: --- Helge Hafting <hel...@hi...> wrote: <snip> > If you have two framebuffers, one for each card, > then I recommend > using framebuffer console and no dumbcon for ruby > 2.6.7. > <snip> I don't understand that. Dense. :-( How do you assign framebuffers to a card? And how many framebuffers do I have? I do "cat <something> > /dev/fb0 or /dev/fb1 and it always ends up on the primary console... Hugo. _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com |
|
From: Helge H. <hel...@hi...> - 2004-09-17 08:14:16
|
Hugo Vanwoerkom wrote: >Hi! > >Still have a question: > >--- Helge Hafting <hel...@hi...> wrote: > ><snip> > > > >>If you have two framebuffers, one for each card, >>then I recommend >>using framebuffer console and no dumbcon for ruby >>2.6.7. >> >> >> > ><snip> > >I don't understand that. Dense. :-( How do you assign >framebuffers to a card? And how many framebuffers do I >have? > > You don't really assign framebuffers yourself. It usually happens automatically, if you have framebuffer drivers for your cards. I have a matrox G550 dualhead card, and my kernel is compiled with two framebuffers for it, one for each head. Therefore, /dev/fb0 is the first head and /dev/fb1 is the second. cat something > /dev/fb0 cause garbage to appear on the first screen, while cat somthing > /dev/fb1 cause garbage on the other screen. Using /dev/fb2 gives me ENODEV because there is no third framebuffer at this time. There will be when I get my radeon pci card though. >I do "cat <something> > /dev/fb0 or /dev/fb1 and it >always ends up on the primary console... > > Very strange. Only one of them should refer to the primary console. Have you tried higher numbers, such as fb2, fb3, and so on? Try "ls -l /dev/fb*" and see if the device numbers are correct. You should get something like this: crw-rw---- 1 root video 29, 0 2004-08-16 15:33 /dev/fb0 crw-rw---- 1 root video 29, 1 2004-08-16 15:33 /dev/fb1 crw-rw---- 1 root video 29, 2 2004-08-16 15:33 /dev/fb2 The date may be different, but the major number should be 29 and the minors should go from 0 and up. The devices must have distinct minor numbers. You can assign keyboards to consoles - once your framebuffer oddities are sorted out. Look at the files in /proc/bus/console For a 2-keyboard machine with one vgacon and one dummycon I have: cat /proc/bus/console/00/display_desc VGA+ cat /proc/bus/console/00/keyboard isa0060/serio0/input0 cat /proc/bus/console/01/display_desc dummy device cat /proc/bus/console/01/keyboard isa0060/serio1/input0 These are changeable. I can swap the two keyboards like this, for example: echo isa060/serio1/input0 > /proc/bus/console/00/keyboard echo isa060/serio0/input0 > /proc/bus/console/01/keyboard (serio1 is the ps2 kbd connector, serio0 is the ps2 mouse connector, where I have another keyboard instead. My mice are serial mice.) Helge Hafting |
|
From: Hugo V. <hvw...@ya...> - 2004-09-17 13:41:40
|
--- Helge Hafting <hel...@hi...> wrote: > You don't really assign framebuffers yourself. It > usually > happens automatically, if you have framebuffer > drivers for > your cards. > > I have a matrox G550 dualhead card, and my kernel > is compiled with two framebuffers for it, one for > each head. I see that option for "matrox" and "dualhead". But I have a nVidia TNT2 on AGP and a nVidia MX-440 on PCI. Like I said, I patched in the vesafb-tng patch. That gives you on the kernel config a default resolution which I set to 1280x1024-32@85 AND I compile in SUN12x22 fonts, but nothing else. Then I get a good screen. The "only" thing is on boot, after the initial vga stuff, the fbcon starts up with a big white blob that moves up and disappears. Now when I disable vesafb and enable nVidia Riva, everything turns to s**t. The screen becomes black with tiny little green things above (that's the part where the penguin shows) and then afterwards the characters become huge (because of the selection of the sun12x22 font). > Therefore, /dev/fb0 is the first head and /dev/fb1 > is the second. > cat something > /dev/fb0 cause garbage to appear on > the > first screen, while cat somthing > /dev/fb1 cause > garbage on > the other screen. Using /dev/fb2 gives me ENODEV > because > there is no third framebuffer at this time. There > will be when I get my radeon pci card though. > > > >I do "cat <something> > /dev/fb0 or /dev/fb1 and it > >always ends up on the primary console... > > > > > Very strange. Only one of them should refer to > the primary console. Have you tried higher numbers, > such as fb2, fb3, and so on? > > Try "ls -l /dev/fb*" and see > if the device numbers are correct. You should > get something like this: > crw-rw---- 1 root video 29, 0 2004-08-16 15:33 > /dev/fb0 > crw-rw---- 1 root video 29, 1 2004-08-16 15:33 > /dev/fb1 > crw-rw---- 1 root video 29, 2 2004-08-16 15:33 > /dev/fb2 I get: crw-rw---- 1 root video 29, 0 Sep 16 07:07 /dev/fb0 crw--w---- 1 root video 29, 1 Mar 14 2002 /dev/fb0autodetect crw--w---- 1 root video 29, 0 Mar 14 2002 /dev/fb0current crw-rw---- 1 root video 29, 1 Sep 16 07:07 /dev/fb1 crw--w---- 1 root video 29, 33 Mar 14 2002 /dev/fb1autodetect crw--w---- 1 root video 29, 32 Mar 14 2002 /dev/fb1current crw-rw---- 1 root video 29, 2 Sep 16 07:07 /dev/fb2 crw--w---- 1 root video 29, 65 Mar 14 2002 /dev/fb2autodetect crw--w---- 1 root video 29, 64 Mar 14 2002 /dev/fb2current crw-rw---- 1 root video 29, 3 Sep 16 07:07 /dev/fb3 crw--w---- 1 root video 29, 97 Mar 14 2002 /dev/fb3autodetect crw--w---- 1 root video 29, 96 Mar 14 2002 /dev/fb3current crw-rw---- 1 root video 29, 4 Sep 16 07:07 /dev/fb4 crw--w---- 1 root video 29, 129 Mar 14 2002 /dev/fb4autodetect crw--w---- 1 root video 29, 128 Mar 14 2002 /dev/fb4current crw-rw---- 1 root video 29, 5 Sep 16 07:07 /dev/fb5 crw--w---- 1 root video 29, 161 Mar 14 2002 /dev/fb5autodetect crw--w---- 1 root video 29, 160 Mar 14 2002 /dev/fb5current crw-rw---- 1 root video 29, 6 Sep 16 07:07 /dev/fb6 crw--w---- 1 root video 29, 193 Mar 14 2002 /dev/fb6autodetect crw--w---- 1 root video 29, 192 Mar 14 2002 /dev/fb6current crw-rw---- 1 root video 29, 7 Sep 16 07:07 /dev/fb7 crw--w---- 1 root video 29, 225 Mar 14 2002 /dev/fb7autodetect crw--w---- 1 root video 29, 224 Mar 14 2002 /dev/fb7current But only catting to /dev/fb0 has any effect. <snip> I now see that I ought to try nVidia riva in the kernel without the sun font or vesafb driver and see if he changes the number of framebuffers. Aivils uses the vesafb-tng patch and if he reads this maybe he can say whether that gets him framebuffers for all his cards OK. See if he replies. All in all: 1. Obviously framebuffers are much slower than direct drivers (like SVGATextMode) 2. But the consoles look very nice. I now have exactly what I have on 2.4.26 (X on PCI vc's + X on AGP). 3. And gpm pastes again... no small thing. 4. And netled uses the keyboard led again, "I think" with less trouble (I maybe wrong). 5. And no garbage on starting the second X. 6. And not having to be in X on AGP when X on PCI restarts. Hugo _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com |
|
From: Hugo V. <hvw...@ya...> - 2004-09-17 20:04:02
|
--- Hugo Vanwoerkom <hvw...@ya...> wrote: > > I now see that I ought to try nVidia riva in the > kernel without the sun font or vesafb driver and see > if he changes the number of framebuffers. > Result: Only catting to /dev/fb0 produces green speckles on the screen. Anything else gets "no such device". Hugo. _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com |
|
From: Aivils <ai...@un...> - 2004-09-20 11:27:17
|
On Friday 17 September 2004 23:04, Hugo Vanwoerkom wrote: > > --- Hugo Vanwoerkom <hvw...@ya...> wrote: > > > > > I now see that I ought to try nVidia riva in the > > kernel without the sun font or vesafb driver and see > > if he changes the number of framebuffers. > > > > Result: > Only catting to /dev/fb0 produces green speckles on > the screen. Anything else gets "no such device". IMHO rivafb does not work for me. vesafb-tng at least have stable maintainer, i choose it. Lone fb driver take over VGA console and so use same vc:1-16. For second X please use same vc:17 That mean - no changes, just compile fbcon into kernel. I am not sure about fbcon and _second_ X server compatibility, because each X try to block video output. Aivils |
|
From: Helge H. <hel...@hi...> - 2004-09-21 07:00:30
|
Aivils wrote: >On Friday 17 September 2004 23:04, Hugo Vanwoerkom wrote: > > >>--- Hugo Vanwoerkom <hvw...@ya...> wrote: >> >> >> >>>I now see that I ought to try nVidia riva in the >>>kernel without the sun font or vesafb driver and see >>>if he changes the number of framebuffers. >>> >>> >>> >>Result: >>Only catting to /dev/fb0 produces green speckles on >>the screen. Anything else gets "no such device". >> >> > IMHO rivafb does not work for me. >vesafb-tng at least have stable maintainer, i choose it. >Lone fb driver take over VGA console and so use >same vc:1-16. For second X please use same vc:17 >That mean - no changes, just compile fbcon into >kernel. >I am not sure about fbcon and _second_ X server >compatibility, because each X try to block video >output. > > 2.6.7 fbcon seems to work fine with dual X servers, at least on the matrox G550. Helge Hafting |
|
From: Helge H. <hel...@hi...> - 2004-09-20 07:40:04
|
Hugo Vanwoerkom wrote: >--- Helge Hafting <hel...@hi...> wrote: > > > >>You don't really assign framebuffers yourself. It >>usually >>happens automatically, if you have framebuffer >>drivers for >>your cards. >> >>I have a matrox G550 dualhead card, and my kernel >>is compiled with two framebuffers for it, one for >>each head. >> >> > >I see that option for "matrox" and "dualhead". But I >have a nVidia TNT2 on AGP and a nVidia MX-440 on PCI. > > Then you need framebuffer drivers for those nvidia cards, if such drivers exists. (Or do without framebuffers.) >Like I said, I patched in the vesafb-tng patch. That > > I don't know what kind of driver this is, vesa is probably some kind of generic framebuffer driver? Such drivers tend to be unaccelearated (ok but slow) and usually only works with the first graphichs card in the system. The second one tend to go unused. A driver made specifically for one kind of card have a better chance for working for a secondary card too. >gives you on the kernel config a default resolution >which I set to 1280x1024-32@85 AND I compile in >SUN12x22 fonts, but nothing else. Then I get a good >screen. The "only" thing is on boot, after the initial >vga stuff, the fbcon starts up with a big white blob >that moves up and disappears. > >Now when I disable vesafb and enable nVidia Riva, >everything turns to s**t. The screen becomes black >with tiny little green things above (that's the part >where the penguin shows) and then afterwards the >characters become huge (because of the selection of >the sun12x22 font). > > > >>Therefore, /dev/fb0 is the first head and /dev/fb1 >>is the second. >>cat something > /dev/fb0 cause garbage to appear on >>the >>first screen, while cat somthing > /dev/fb1 cause >>garbage on >>the other screen. Using /dev/fb2 gives me ENODEV >>because >>there is no third framebuffer at this time. There >>will be when I get my radeon pci card though. >> >> >> >> >>>I do "cat <something> > /dev/fb0 or /dev/fb1 and it >>>always ends up on the primary console... >>> >>> >>> >>> >>Very strange. Only one of them should refer to >>the primary console. Have you tried higher numbers, >>such as fb2, fb3, and so on? >> >>Try "ls -l /dev/fb*" and see >>if the device numbers are correct. You should >>get something like this: >>crw-rw---- 1 root video 29, 0 2004-08-16 15:33 >>/dev/fb0 >>crw-rw---- 1 root video 29, 1 2004-08-16 15:33 >>/dev/fb1 >>crw-rw---- 1 root video 29, 2 2004-08-16 15:33 >>/dev/fb2 >> >> > >I get: > >crw-rw---- 1 root video 29, 0 Sep 16 07:07 /dev/fb0 >crw--w---- 1 root video 29, 1 Mar 14 2002 >/dev/fb0autodetect >crw--w---- 1 root video 29, 0 Mar 14 2002 >/dev/fb0current >crw-rw---- 1 root video 29, 1 Sep 16 07:07 /dev/fb1 >crw--w---- 1 root video 29, 33 Mar 14 2002 >/dev/fb1autodetect >crw--w---- 1 root video 29, 32 Mar 14 2002 >/dev/fb1current >crw-rw---- 1 root video 29, 2 Sep 16 07:07 /dev/fb2 >crw--w---- 1 root video 29, 65 Mar 14 2002 >/dev/fb2autodetect >crw--w---- 1 root video 29, 64 Mar 14 2002 >/dev/fb2current >crw-rw---- 1 root video 29, 3 Sep 16 07:07 /dev/fb3 >crw--w---- 1 root video 29, 97 Mar 14 2002 >/dev/fb3autodetect >crw--w---- 1 root video 29, 96 Mar 14 2002 >/dev/fb3current >crw-rw---- 1 root video 29, 4 Sep 16 07:07 /dev/fb4 >crw--w---- 1 root video 29, 129 Mar 14 2002 >/dev/fb4autodetect >crw--w---- 1 root video 29, 128 Mar 14 2002 >/dev/fb4current >crw-rw---- 1 root video 29, 5 Sep 16 07:07 /dev/fb5 >crw--w---- 1 root video 29, 161 Mar 14 2002 >/dev/fb5autodetect >crw--w---- 1 root video 29, 160 Mar 14 2002 >/dev/fb5current >crw-rw---- 1 root video 29, 6 Sep 16 07:07 /dev/fb6 >crw--w---- 1 root video 29, 193 Mar 14 2002 >/dev/fb6autodetect >crw--w---- 1 root video 29, 192 Mar 14 2002 >/dev/fb6current >crw-rw---- 1 root video 29, 7 Sep 16 07:07 /dev/fb7 >crw--w---- 1 root video 29, 225 Mar 14 2002 >/dev/fb7autodetect >crw--w---- 1 root video 29, 224 Mar 14 2002 >/dev/fb7current > >But only catting to /dev/fb0 has any effect. > ><snip> > >I now see that I ought to try nVidia riva in the >kernel without the sun font or vesafb driver and see >if he changes the number of framebuffers. > >Aivils uses the vesafb-tng patch and if he reads this >maybe he can say whether that gets him framebuffers >for all his cards OK. See if he replies. > >All in all: >1. Obviously framebuffers are much slower than direct >drivers (like SVGATextMode) > > SVGATextMode uses the vga text console. It is fast because an entire character is written by writing two bytes only. (A character byte and a color byte.) Downsides: * Can't display graphichs on it, obviously * Limited to 256 or 512 simultaneous different characters on screen, so chinese text is tricky at best * No multicolored fonts * Font limitations, a character must be 8 or 9 pixels wide. A framebuffer have to paint each character as graphichs. That is always more than 2 bytes: Best case: 1-bit color depth (monochrome) 8x8 font, -> 8 byte per character. Bad case: 12x22 font, 24-bit color: 792 byte per character! It doesn't have to be slow though, some framebuffer drivers use the on-chip graphichs accelerator. (Same as X uses) They may then match vgacon for speed. :-) I don't think any VESA thing can use the accelerator though. Other message: >Result: >Only catting to /dev/fb0 produces green speckles on >the screen. Anything else gets "no such device". > > This shows that the framebuffer driver for your first screen is fine, and you have no framebuffer driver loaded for the other screen. If the _same_ driver is supposed to be able to drive both cards, then you might need to tell it by giving it the right parameters. I don't know your cards but they have different names, perhaps they need different drivers? One way of testing is to temporarily remove the AGP card and see if the driver then is capable of driving the PCI card as /dev/fb0. If so, look at documentation (or source) and try to find parameters that makes the driver drive two cards. 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