linuxconsole-dev

Re: Future of Ruby: head for the hills

[Erik W. <om...@vc...>]

Hugo Vanwoerkom wrote:
> The problems with multiple VGA cards, etc, are much
> harder to solve, though. 

Tell me about it.  3+ solid weeks and no go.

I've traced the problem with my system down to DPMS, where the Radeon
driver thinks it's waking up the display (confirmed with initial
instrumentation of the driver), but it never does.  Unfortunately the
hardware is being packed up in 1 hour and gets on the plane to Bolivia
at 7:15am tomorrow morning, so I just bought hardware for 4 more
separate computers that we'll try to find space for in our crates.

OTOH, I've been running the core machine with just one video card and X
server for the last few hours while I was "shopping", and came back to
an X display that wouldn't wake up either.  The only unusual setting in
the xorg.conf appears to be VGAAccess "false", which is required for the
multi-head configuration to work without the servers crushing each other.

I've just removed the VGAAccess option from the server and started it
up, we'll see if it goes to sleep permanently as well.  If so,
something's wrong with this particular combination of driver and card,
relative to DPMS.  If not, then I've narrowed the problem down a little
bit more, except that I don't see any obvious "VGA-class" operations in
the DPMS code, just normal Radeon register pokes.

Single-server multi-head (xinerama and not) seems to work just fine with
DPMS, but I haven't had much in the way of exhaustive testing, simply no
time at the moment.

Once I get back in 2 weeks I'll be either ordering cards or using ones
left behind (new mobos might have onboard video, haven't checked that
yet) and hammering as hard as I can on this problem.  This, and the
inability for the X server to do VGA BIOS initialization if SingleCard
is "true", seem to be the only issues remaining to getting multi-seat X
working, not counting all the misc configuration issues, and
complications with other perhipherals like sound etc.  Those come next.

I would welcome help from anyone who's interested, including the Ubuntu
multiseat guys, X and console coders, etc.  I think multi-seat systems,
if they can be made stable and easy to build, are going to be a huge
deal in less developed countries, due to cost, power, and space concerns.

Future of Ruby: head for the hills

[Hugo V. <hvw...@ya...>]

Hi,

Found a neat quote from  Vojtech Pavlik in
fa.linux.kernel (Sep 1, 7:23 am):

==========================================
> (When) Will there ever be native kernel (and maybe
XFree) support for
> multiple independent keyboards?

The kernel console is unlikely to ever going to have
that - noone is interested in changing the console
subsystem.

The current state of input device support in the
kernel, however, allows any userspace program to
access them independently, including keyboards.

That means multi-user X and possibly a userspace
console implementation (Jon Smirl is planning one) has
no barriers in the kernel input device implementation
keeping it from proceeding.

The problems with multiple VGA cards, etc, are much
harder to solve, though. 
==============================================

I don't know Jon Smirl, but Aivils of course already
has such a solution with Faketty, working very well,
thank you.

So head for the hills and while you are running hope
Aivils is running with you.

Hugo









__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

=?iso-8859-1?Q?Re:_Really_Works_Wonder_-_Ph=E5rmaceutical?=

[Sharyn D. <sh...@la...>]

CiCeAmViUlLeVaPrXaMe
allebiagtrviliopnari
isbrexenraamtraumeciaxdia
99 72 68 69 85 99 85=
64 12 99
75.00.00.85.5=
5.94.45.953.45.96
our website=
 bearded fellow who was smoking a hand-rolled cigarette, sitting beside a or =
other!

Re: faketty + vt7

[Hugo V. <hvw...@ya...>]

--- Aivils Stoss <ai...@un...> wrote:

> On Ceturtdiena, 1. Septembris 2005 21:11, Hugo
> Vanwoerkom wrote:

<snip>

> 
> Here is quite different layers. TTY and faketty.
> Both
> are completely independ, exluding LED handling.
> faketty do not knows nothing about VT-handlig.
> faketty
> send necessary characters to device file fttyXX.
> When
> userspace program opens fttyXX, then faketty grab
> that
> device and input events goes to faketty only.
> 
> This trick became possible besause of new input
> layer.
> Under new input layer every body can register
> unlimited
> count of event handlers of each input device.
> Current
> exist kbd mouse event. These 3 generates events via
> assigned device files with proper protocol.
> 
> Charaters, which runs via TTY in "RAW" mode, looks
> very simple for me. I face up to new handler. Code
> is as simple as possible. for that reason some
> ioctl's
> like bell are cleaned up but wholly possible.
> VT-handling is totally impossible. From view point
> of
> angry kernel developer that all is duplicate code.
> 
> Keyboard soft IRQ handler does not take care for
> grabed
> devices, so LED handling is exlusive and hijacked
> for the
> sake of text mode console.
> 
> You are wellcome to rewrite that damn readme :-)
> 

I still feel too uncertain of the technical issues.
Otherwise I would have thought of the solution. When
did it occur to you?

Under separate subject I am posting that I find
Faketty a better solution for my setup.

Hugo








__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Faketty vs. Ruby

[Hugo V. <hvw...@ya...>]

Hi,

I may be jumping the gun, but anyway.

In this setup:
Epox-EP8vtai mobo + XP 2700+ thoroughbred CPU
AGP TNT2 + PCI MX-440
Linux distro: Debian Stable
Kernel: vanilla 2.6.11

I have installed Aivils' Faketty + Hijacled.

The X on the secondary monitor runs as usual. No
problems.

But on the primary monitor, Ruby's problems have
disappeared:
- Screens no longer disappearing or blanked.
- Keystrokes from secondary keyboard no longer bleed
over to vc textscreens on primary monitor.
- Meta keycodes work.
- Mouse gpm works with pasting.

All very encouraging. Am running with it right now.

Aivils' has described what it does in the various
recent posts under different subject headers.

For my setup I had to reverse the ftty links and the
install has to be tweaked for Debian.

Hugo











		
____________________________________________________
Start your day with Yahoo! - make it your home page 
http://www.yahoo.com/r/hs 
 

Re: faketty + vt7

[Aivils S. <ai...@un...>]

On Ceturtdiena, 1. Septembris 2005 21:11, Hugo Vanwoerkom wrote:
> Hi,
>
> I'll start a new thread to make searching a little
> easier.
>
> Everything with faketty works and more.
>
> My setup again: AGP=TNT2 PCI=MX-440.
>
> If I start gdm with:
>
> name=Standard server
> command=/usr/X11R6/bin/X0 :0 -layout X0 -deferglyphs
> 16 -isolateDevice \"PCI:1:0:0\" vt50
> flexible=true
>
> # Definition of the second X server.
> [server-2nd]
> name=2nd server
> command=/usr/X11R6/bin/X1 :1 -layout X1 -deferglyphs
> 16 -isolateDevice \"PCI:0:10:0\" vt51
>
> I get garbage on the AGP, little speckles that follow
> the mouse in 3 different places on the screen. PCI
> screen is fine.
>
> And I cannot use Alt+Ctrl+Fx to switch to a text vc.
>
> If I change this to (I found this by mistake):
>
> name=Standard server
> command=/usr/X11R6/bin/X0 :0 -layout X0 -deferglyphs
> 16 -isolateDevice \"PCI:1:0:0\" vt7
>
> The garbage disappears and I can switch to a text
> console and back.
>
> Why does this work? So faketty got me Ruby free and
> everything works as before. My power typist for the
> PCI monitor hasn't shown up to see if I get those
> keyboard overflows on my textconsole.

Here is quite different layers. TTY and faketty. Both
are completely independ, exluding LED handling.
faketty do not knows nothing about VT-handlig. faketty
send necessary characters to device file fttyXX. When
userspace program opens fttyXX, then faketty grab that
device and input events goes to faketty only.

This trick became possible besause of new input layer.
Under new input layer every body can register unlimited
count of event handlers of each input device. Current
exist kbd mouse event. These 3 generates events via
assigned device files with proper protocol.

Charaters, which runs via TTY in "RAW" mode, looks
very simple for me. I face up to new handler. Code
is as simple as possible. for that reason some ioctl's
like bell are cleaned up but wholly possible.
VT-handling is totally impossible. From view point of
angry kernel developer that all is duplicate code.

Keyboard soft IRQ handler does not take care for grabed
devices, so LED handling is exlusive and hijacked for the
sake of text mode console.

You are wellcome to rewrite that damn readme :-)

Aivils

faketty + vt7

[Hugo V. <hvw...@ya...>]

Hi,

I'll start a new thread to make searching a little
easier.

Everything with faketty works and more.

My setup again: AGP=TNT2 PCI=MX-440.

If I start gdm with:

name=Standard server
command=/usr/X11R6/bin/X0 :0 -layout X0 -deferglyphs
16 -isolateDevice \"PCI:1:0:0\" vt50
flexible=true

# Definition of the second X server.
[server-2nd]
name=2nd server
command=/usr/X11R6/bin/X1 :1 -layout X1 -deferglyphs
16 -isolateDevice \"PCI:0:10:0\" vt51

I get garbage on the AGP, little speckles that follow
the mouse in 3 different places on the screen. PCI
screen is fine.

And I cannot use Alt+Ctrl+Fx to switch to a text vc.

If I change this to (I found this by mistake):

name=Standard server
command=/usr/X11R6/bin/X0 :0 -layout X0 -deferglyphs
16 -isolateDevice \"PCI:1:0:0\" vt7

The garbage disappears and I can switch to a text
console and back.

Why does this work? So faketty got me Ruby free and
everything works as before. My power typist for the
PCI monitor hasn't shown up to see if I get those
keyboard overflows on my textconsole.

Hugo



__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: No patches any more - fake tty driver

[Aivils S. <ai...@un...>]

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

Re: No patches any more - fake tty driver

[Hugo V. <hvw...@ya...>]

--- 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 

Re: No patches any more - fake tty driver

[Aivils S. <ai...@un...>]

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

=?iso-8859-1?Q?Re:_ox4_Offr_for_you_VIAGRR=C1?=

[Cadell W. <ca...@da...>]

 Dont worry. Ill never forget anything now, he replied. barked: of the truck =
and raised his arm, for some reason attacking the cast-iron man The second =
said: But unfortunately only in parable. stove, a portable one-burner stove =
fuelled with pressurized benzene, made Yeshua. And straight away, looking at =
the threads of fire cutting up the I want my beloved master to be returned to =
me right now, this second, same one. records? Tell me, what happened =
afterwards with Yeshua and Pilate? Ivan asked. inflamed and frightened eyes, =
carrying no luggage and dressed somewhat you to go on a little excursion with =
him - if you wish, of course. What do a policeman. organizing choral-singing =
clubs. time at Satans ball. In his stories of how he had carried Margarita He =
dashed to the chest, pulled a drawer out with a clatter, and from it

Re: No patches any more - fake tty driver

[Aivils S. <ai...@un...>]

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

Re: No patches any more - fake tty driver

[Hugo V. <hvw...@ya...>]

--- 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 

Re: No patches any more - fake tty driver

[Aivils S. <ai...@un...>]

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

Re: No patches any more - fake tty driver

[Hugo V. <hvw...@ya...>]

--- 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 

Re: Multi-seat X crashes

[Erik W. <om...@vc...>]

Helge Hafting wrote:
> I think you may cut down on the time for this by starting (and killing)
> one xserver that uses all the screens at once.  It will then initialize
> all those
> adapters.  This should be a safe approach, as xserver support for using
> many cards (for a single user) is very old.  You'll need an extra xorg.conf
> file of course.
Thanks, that works nicely.  I'll have to do some major changes to my
scripts if I'm going to make it semi-automagic, but for now hardcoding
works.  It probably cut the time in half, the remaining time being VGA
BIOS initialization.

> Anyway, loading the framebuffer driver _after_ this initialization
> completes, is supposed to work.  Make sure the driver isn't
> present before though, or it will give up too early on those
> uninitialized cards.
Now I'm having problems getting the fbdev driver to work.  Even with
only one card in the machine and a config file generated by
`dpkg-reconfigure xserver-xorg` for fbdev, it fails with:

(EE) FBDEV(0): FBIOPUT_VSCREENINFO: Invalid argument
(EE) FBDEV(0): mode initialization failed

I'm getting 2.6.11 built, so I can build a backstreet-ruby version as
suggested to maybe deal with bus issues.  I'll also try the
just-released 2.6.13 as /. made mention of significant PCI changes,
which if I'm really hitting a bus contention issue (whcih I've suspected
from the beginning but have not the slightest chance of confirming)
might make a difference one way or another...

Re: Multi-seat X crashes

[Fredrik T. <fr...@do...>]

On Sun, 2005-08-28 at 16:50 -0700, Erik Walthinsen wrote:
> Fredrik Tolf wrote:
> > With 6 video cards, have you considered the possibility that it might
> > simply be a problem with heat dissipation?
> 
> Considered it, yes, and confirmed it's not the issue (though I really
> wish it were, cause the solutions are easy).  Neither is power.  The
> cards are all Radeon 7000's with very little heat dissipation and power
> use, and I've both beefed up the power supply with no change, and have
> an 80mm fan blowing straight onto them.  There is no discernable heat
> when touching the cards' heatsinks.
> 
> Besides, it happens with just two cards in the machine as well ;-(

Bummer...

Even so, however, I get the distinct feeling that this is because of
some kind of bus lockup or similar, rather than a kernel panic --
especially since you stated earlier that you hadn't even patched your
kernel with ruby.

In fact, why not try patching the kernel with ruby and see if that
works? It might just be worth a shot...

Fredrik Tolf

Re: Multi-seat X crashes

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

Erik Walthinsen wrote:

>Helge Hafting wrote:
>  
>
>>There are further difficulties
>>if you're trying for a fb per head on a multihead card, but one
>>fb per card is supposed to work.
>>    
>>
>AFAIK only the Matrox fb driver currently actually does multiple fb
>devices.  Though Radeon cards have had multiple CRTCs for years now...
>
>  
>
>>The device-nodes /dev/fb1, /dev/fb2, and so on exists?
>>    
>>
>Via udev, yes, as needed.
>
>  
>
>>What happens if you compile the framebuffer driver into the kernel,
>>instead of using a module?  Or if you tries to load that module
>>a second time?
>>    
>>
>I'll try compiling it in, but I don't think I can load the module
>multiple times.
>
>  
>
>>It likely won't, though.  There is a way around this, but it is long.
>>    
>>
>This is basically what I'm doing to initialize the cards currently, with
>a script that starts up and kills each X server in sequence, with
>SingleCard "false".  Otherwise the SingleCard "true" server for any but
>the "primary" card will lock the machine at startup.
>
>  
>
I think you may cut down on the time for this by starting (and killing)
one xserver that uses all the screens at once.  It will then initialize 
all those
adapters.  This should be a safe approach, as xserver support for using
many cards (for a single user) is very old.  You'll need an extra xorg.conf
file of course.

Anyway, loading the framebuffer driver _after_ this initialization
completes, is supposed to work.  Make sure the driver isn't
present before though, or it will give up too early on those
uninitialized cards.

>Is there any code out there to execute the int10 VGA BIOS without having
>to start up a whole X server?
>  
>
Not that I know of.  One approach could be to extract this code from
the X codebase, and throw away the rest of X.

Helge Hafting

Re: Multi-seat X crashes

[Erik W. <om...@vc...>]

Helge Hafting wrote:
> There are further difficulties
> if you're trying for a fb per head on a multihead card, but one
> fb per card is supposed to work.
AFAIK only the Matrox fb driver currently actually does multiple fb
devices.  Though Radeon cards have had multiple CRTCs for years now...

> The device-nodes /dev/fb1, /dev/fb2, and so on exists?
Via udev, yes, as needed.

> What happens if you compile the framebuffer driver into the kernel,
> instead of using a module?  Or if you tries to load that module
> a second time?
I'll try compiling it in, but I don't think I can load the module
multiple times.

> It likely won't, though.  There is a way around this, but it is long.
This is basically what I'm doing to initialize the cards currently, with
a script that starts up and kills each X server in sequence, with
SingleCard "false".  Otherwise the SingleCard "true" server for any but
the "primary" card will lock the machine at startup.

Is there any code out there to execute the int10 VGA BIOS without having
to start up a whole X server?

Re: Multi-seat X crashes

[Erik W. <om...@vc...>]

Fredrik Tolf wrote:
> With 6 video cards, have you considered the possibility that it might
> simply be a problem with heat dissipation?

Considered it, yes, and confirmed it's not the issue (though I really
wish it were, cause the solutions are easy).  Neither is power.  The
cards are all Radeon 7000's with very little heat dissipation and power
use, and I've both beefed up the power supply with no change, and have
an 80mm fan blowing straight onto them.  There is no discernable heat
when touching the cards' heatsinks.

Besides, it happens with just two cards in the machine as well ;-(

Re: Multi-seat X crashes

[Fredrik T. <fr...@do...>]

On Fri, 2005-08-19 at 00:53 -0700, Erik Walthinsen wrote:
> I've got a system I'm building for a school in a small isolated Andean
> town in Bolivia, and I'm leaving on Sept 4th to go install it.  Problem
> is, it's currently crashing ;-(
[...]
> The problem is that the machine will then seize up with no warning
> anywhere from ~5 to ~30 minutes after starting up GDM.  This happens
> whether I am using one of the heads or not, and whether I've even
> *touched* the system or not.  It just as regularly happens when I've
> just gone through the entire Ubuntu package list in Synaptic and am
> about to start downloading (sigh!) as when I'm not even in the same room
> and have started GDM remotely.

With 6 video cards, have you considered the possibility that it might
simply be a problem with heat dissipation?

--
Fredrik Tolf

Re: Multi-seat X crashes

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

Erik Walthinsen wrote:

>Erik Walthinsen wrote:
>  
>
>>>Third workaround: Configure framebuffers in your kernel,
>>>get a framebuffer for each and every screen.
>>>      
>>>
>>This is something I tried for a while, but didn't have much luck with.
>>I'll give it another shot though.
>>    
>>
>
>No go.	When loading the radeonfb module, I get /dev/fb0 for the first
>card, but no other cards load up.  They all come back with "0k" VRAM and
>refuse to create an FB device.  There are hacks in the driver for a
>couple of video cards to deal with this situation, but not for the same
>reason.
>  
>
According to Documentation/fb/framebuffer.tct, you are supposed
to get a fb for each _card_ at least.  There are further difficulties
if you're trying for a fb per head on a multihead card, but one
fb per card is supposed to work. 
The device-nodes /dev/fb1, /dev/fb2, and so on exists?

What happens if you compile the framebuffer driver into the kernel,
instead of using a module?  Or if you tries to load that module
a second time?

Also make sure vesafb is disabled (or the module _not_ loaded),
for vesafb just gets in the way and supports only one card.




Wait...  You say they come up with 0k VRAM and refuse to load.
That is typical for the case where the cards were found, but
the bios haven't initialized them.  If all your cards are the same type,
check to see if the bios have an option for initializing more than one
cards. 

It likely won't, though.  There is a way around this, but it is long.
Basically:
1. boot the machine. Make sure _no_ framebuffer modules load
    at this time.
2. Run X briefly.  This special X should be configured to simply use
    all the cards, and initialize them via the int10 routine.
    This way, every card will get their bios initialization.  Make sure
    this Xserver quits after initialization.  For example, it could
    use /bin/false as "window manager".
3. _Now_ load the framebuffer driver.  It should find that all the cards
    are initialized and have enough RAM and so on.  You should get
    a framebuffer (but not a console) for each screen.  You may verify 
this by
    cat somefile > /dev/fb1
    cat somefile > /dev/fb2
    ...
    and see how garbage appear on each screen as "somefile" contents
    is written to video memory.
4. Now start your regular xservers, those that use the framebuffers
    for managing resolution.

Helge Hafting

Re: Multi-seat X crashes (still need help!)

[Erik W. <om...@vc...>]

Helge Hafting wrote:
> I don't know, but I'll look at it someday.  I too have this problem,
> restarting X on my secondary card messes up the display
> on the first, which can be solved by tapping ctrl, alt, and the
> big plus on the keypad.  Works for me, but my users get so confused.

I don't have any problems with starting up, I've managed to get around
the various problems there, partially by using the hack of starting each
server *without* SingleCard one at a time first, to initialize the VGA
BIOS cleanly.

The problem still remains that once the system is up, it will crash
periodically, with no obvious trigger event.  It's crashing so hard that
KGDB doesn't even work.

I'm out for the weekend, so I have Monday through Friday of next week to
try to resolve this, or I'm going to have to go down there and cobble
together as many single-headed systems as I can manage from the few
scrap bits of hardware they had in the pictures I saw.  Not a good
solution. ;-(

Re: Multi-seat X crashes

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

Erik Walthinsen wrote:

>Helge Hafting wrote:
>  
>
>>This is probably the classic problem where an xserver mistakenly
>>thinks it has the "only" vga-compatible card in the box, and
>>tries reprogramming video timings using legacy vga hardware
>>addresses that might affect the wrong card.
>>    
>>
>Isn't this what the "VGAAccess" "false" option is for?
>  
>
I don't know, but I'll look at it someday.  I too have this problem,
restarting X on my secondary card messes up the display
on the first, which can be solved by tapping ctrl, alt, and the
big plus on the keypad.  Works for me, but my users get so confused.

Maybe vgaaccess helps.  Maybe using the framebuffer option
will help, according to the docs I'll still get acceleration, but
X will use the framebuffer drivers to do resolution changes.  That
_should_ remove trouble upon x restart, when X tries to set the resolution.

>  
>
>>Third workaround: Configure framebuffers in your kernel,
>>get a framebuffer for each and every screen.
>>    
>>
>This is something I tried for a while, but didn't have much luck with.
>I'll give it another shot though.  Accelleration isn't a huge deal, and
>3D is out with multiple cards anyway, so speed should be acceptible.
>  
>
Actually, 3D isn't out with multiple cards.  I can run 3D both
on my matrox G550 and the radeon 9200 SE at the same time.
It is not _stable_, the kernel will occationally trip up freezing one
or both displays.  So  I don't use it.  But this is merely a bug in
the radeon driver. The kernel, the DRI/DRM 3D systems really support
multihead 3D these days.  My problems is not a result of
dual-seat, running 3D on the radeon alone can go wrong too.

>What I'd really like to be able to do is get both heads of the
>dual-headed cards running separate framebuffers, and get separate X
>servers running on those.  That would let me get away with only 3 video
>cards for 6 heads, freeing other PCI slots for either other cards, or
>smaller motherboards.  Problem is, I couldn't figure out if it is even
>possible to have separate /dev/fb devices with the kernel fb driver...
>  
>
It is possible, but only if the framebuffer driver for that particular
card supports it.  The driver for matrox G550 (and G400)
supports this.  Most other drivers doesn't, so this
really limits your options when buying video cards.
I've done it with the G550 though, when the radeon's
old predecessor died.  I then got the radeon, and got disappointed
with its 3D instability.  So I use it without 3D, mostly because the
G550 seems to dislike 24-bit color which I like. :-/

Matrox also have some cards that really are "two/four cards in one",
in that the pci subsystem believes there are two cards instead of
one.  So they work exactly as two (or four!) cards when setting up
the software. (Kernel framebuffer drivers & xservers.)  But
they don't use up that many slots.  Very expensive though.
Of course a "double" card can justify double price, but they're worse.

>Everything I tried was either 5+ years old and didn't exist anymore, or
>didn't work in the slightest otherwise.
>  
>
Well, matrox works, although old.  And I believe you still can
order the cards too.  "old" shouldn't be a problem if you
consider unaccelerated 2D-only ok though.  (Actually, software
3D rendering works fine with such setups.  Way too slow for a
first-person 3D game of course, but ok for some other
programs like frozen-bubble which isn't really 3D but needs
opengl precence anyway.

Helge Hafting

Re: No patches any more - fake tty driver

[Aivils S. <ai...@un...>]

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