Re: Independ multiple users on G550

[Helge H. <hel...@ai...>]

Svetoslav Slavtchev wrote:
[...]
>>So I tried a modular fbcon, with a kernel configured to load
>>modules automatically when needed.  This booted in the same way,
>>loaded the fbcon module automatically and crashed just as the compiled-in
>>variant.  The readable part of the crash message said something
>>about mdrun exiting with a wrong preempt count. 
> 
> no devide errors ?
>  
Hard to say what it was, because the screen was partially garbage.
The last line was a complaint about the kernel trying
to kill init (and therefore giving up).

> Aivils said that it should be fixed in his last tarball & cvs,
> but i still get the devide errors and the prevoius patch fixes them
> /* see attachments */
> 
> 
> 
>>So I moved fbcon.ko where modprobe couldn't find it, and
>>booted again.  The machine came up fine, obviously without a
>>console.  I moved the module back to its proper place,
>>and loaded it.  I immediately got two penguins (it's a dual processor
>>machine) on the screen running accelerated X.  This screen
>>has the keyboard connected to the ordinary ps2 keyboard plug
>>(recognized by the bios too).
> 
> 
> i don't get much this part :(
> 
> you booted with built in matroxfb, but no fbcon,
> and then loaded fbcon without problems ?
> 
Yes.  I usually compile my kernels with everything built-in
because I see no virtue in modules.  (They may be fine for
distribution kernels, but mu kernel is compiled for my machine
specifically.  I simply want to avoid all module setup & management,)

I made an exception here, by configuring fbcon as a module.  The
framebuffer driver and everything else still was compiled-in.

The part about temporarily moving fbcon.ko where modprobe couldn't
find it was just a hack to make the machine boot.  The module
crashes the kernel if it is loaded "too early", but the module
cannot be automatically loaded by the kernel if the
kernel cannot find it because I moved the file away from
its usual directory.

So it seems the framebuffer driver alone works under ruby,
even when compiled in.  fbcon works too, _if_ it
isn't loaded too early.  Bringing it up after
logging in via xdm were ok.

>> Ruby places this at vt17. 
>>Pressing ctrl+alt+F1 here did nothing, no console switch.
> 
> 
> you need this Xfree hack 
> http://sourceforge.net/mailarchive/message.php?msg_id=6629651
> 
> /* if you were running mdk9.2/ cooker i could send you my binary,
>  * but IIRC you use debian
>  */ 
Thanks for the tip. It'll be useful when I get rid
of the crash.

> 
>>The other keyboard is connected to the ps2 mouse plug,
>>and seen by X on vt7. Pressing ctrl+alt+F1 switched to a
>>console.  X blanked itself. Unfortunately the console appeared at the
>>other
>>screen - so I had matrox console and X running there simultaneously.
>>Psycho circus again. :-(  The second screen just sat there.
> 
> 
> looks interesting 
> have a snapshot ?-)
> 
I don't have one, but it isn't all that hard to imagine.
At its best it looks like a ordinary console screen with
an xterm overlayed somehow.  One keyboard types into the
xterm, the other into the console.  Of course the two tend
to stomp on each other quite a bit, the console scrolling
the x desktop away and X repainting a bit here and there
now and then.

> 
>>I believe this might work better if I ran the vt7 xfree on 
>>the first display, but I have a good reason for not doing so:
>>It is sometimes necessary to access the bios setup, or boot non-ruby
>>versions of linux. In those cases the keyboard connected to the
>>ordinary keyboard plug is the only keyboard, and X happens
>>on the first screen. (/dev/fb0).  Moving keyboards or screens around the
>>room isn't very interesting, so this is the layout I want.
>>
>>Life would be so much easier if ruby considered the ordinary
>>pc keyboard as the first one, and one connected to the "mouse" port
>>as the second one.  Or if the vt/keyboarddevice/console connections
>>could be specified using kernel parameters. any hope of swapping the
>>keyboards so the console/screen/keyboard/vt combination that works
>>for plain linux simply becomes the "first" set of connected devices 
>>using ruby?
> 
> 
> just configure hotplug, install input.agent & input.rc 
> /* debian's hotplug pkgs probably already include the input.* scripts
>  * so you'll probably have to merge the ruby input.agent into the debians
> one
>  */
> 
> this way  you can configure VT- keyboard mapping 
> & consistent evdev[n] mouse[n] devices
> /* although udev is probably much better for the evdev & mice */
> 
I'll look at this someday.  Do I need modules for this to work?

>>Is there anything I could do to help find out why fbcon oopses
>>when it is available "too early"?  Perhaps it uses resources
>>not yet initialized?  Or races somehow?  
>>It seems to work when loaded after the normal boot, except that
>>it don't match my screen/keyboard mapping.
> 
> 
> if it is the same issue /* and i think it is */
> it was font.width == 0 + a function using  xxxx / fonth.width
> 
> best
> 
> svetljo
> 
> PS.
> i haven't tried yet built in matroxfb/ fbcon
I'll try your patches.  
I like the built-in approach, it is nice to be able to
boot with init=/bin/sh and still get a console.

The dream is to just boot and get login prompts on
both screens with no further setup than running the 
gettys from /etc/inittab, and perhaps some kernel boot parameters.

The big problems with setup scripts is that they run late in the
boot process, early oopses or other trouble may prevent them
from running, I still want to read the text and be able to use sysrq.

I may go for modules and scripts for now, but hope the monolithic
approach will work someday. :-)
> 
> PS.2
> i use this script to start multiple fbcon's 
Thanks
> 
> PS.3
> attachments
> 
> 260t9-20031115.txt  -- oopses with vanilla ruby-260t9-20031115
> 
> AA02-ruby-20031029_matroxfb_fix.patch - fixes the problem, 
I'll try.

> the remaining issues 
> /* most likely hardware limitations involved 
>  * and XFree "bugs" too
>  */
> 
> 1.)  X->VT->X on head1 (vt7)
> X head1 is displayed on both heads, VT switch on head2 fixes it
> 
I believe this is an issue with the mga accelerated driver.
I get similiar problems whenever games change resolution on
the accelerated head.  I have my window manager set up with a key
combination that runs matroxset.  It'd be nice not
having to do this, but it'll probably be a long time.
X simply do more than it should.

> 2.) the mentioned XFree hack should be integrated smarter,
> currently you need additional binary for each additional fbcon
> 
> 3.) probably unsolvable/ hardware
> the need to run swapped from matroxset tarball to
> separate the displays
I don't see why this should be unsolvable.  All matroxset do is
to run some ioctl's.  Surely the same code could be called from
within the framebuffer driver at boot time?  

I believe this was done because single-monitor setups are
common, and the kernel probably can't easily know where that
monitor is attached.  (Well, it could use DDC...)

But people don't buy a G550 to run single-monitor, so
having the kernel separate the displays and force the user
to think about which connector to use is fine with me.


> 
> 4.) related to 3
> after swapped, both heads are blank until a VT switch, 
> 
> and on head1 there is a lot of garbage until login + logout
> actually the garbage is on all vc's except the first one (head 1)
> but on all vc's usable is only 4/6 of the hight of the screen
> the top 1/6 is ocupied by the logo, the bottom 1/6 by nothing
> on vc1 and by garbage on vc2-vc6. 
I believe the garbage is stuff that vgacon left in graphichs memory before
handing the console over to the framebuffer.  At least this was the 
explanation when I complained about similiar garbage on a radeon
with framebuffer.  compiling _without_ vgacon indeed made all
the garbage go away, but the option to turn off vgacon recently
disappeared from menuconfig. :-( 

> Everything becomes normal after a login + logout , but until logout
> only graphics(e.g. ncurses menuconfig)  paint to the entire screen,
> a ls, ps, whatever will use only the middle 4/6 of the screen hight 
> 
Probably the logo code reserving some of the screen.  Odd that
it'd reserve the bottom part though.

Helge Hafting