linuxconsole-dev

Re: Pharmaaccy-TUU

[Lakshman L. <Ca...@fu...>]

Hello, 

Have a nice day.

Re: Ruby redux

[Jeremy G. <j....@lo...>]

On Tue, 2005-03-01 at 13:47 +0200, Aivils wrote:
> Hi Zoltan!
> 
> 	Now we have linux-ruby against mm. What comes next?
> http://www.ltn.lv/~aivils/files/test/ruby-2.6.11-rc4-mm1-3.diff.bz2
> 
> Aivils Stoss

ck-sources ?

-Jeremy

Re: Ruby redux

[Zoltan B. <zb...@fr...>]

Aivils =EDrta:
> Hi Zoltan!
>=20
> 	Now we have linux-ruby against mm. What comes next?
> http://www.ltn.lv/~aivils/files/test/ruby-2.6.11-rc4-mm1-3.diff.bz2
>=20
> Aivils Stoss

Hm. In vty_init(), we disabled this with "#if 0":

  #ifdef CONFIG_MDA_CONSOLE
         mda_console_init();
  #endif

We should port the mdacon to Ruby, too.
Maybe someone with an old machine with both VGA and MDA,
can help us with testing. I have neither an one, nor an ISA slot..

And Linux supports other architectures beside ix86 and x86-64,
we ask for help from the different arch maintainers, so we can
or they will port the arch-specific parts.

But in this state, we can start the discussion with the kernel
maintainers. Andrew Morton will have a few kind words for us, I think.

I don't know what backwards compatibility we lose with the Ruby
patch. Think about configuring both vgacon and mdacon into the
old kernel. What vtXX will mdacon use? Is there any software that use
it for display-only mode? Will they work on ruby kernel with only
one keyboard, too, unmodified?

And recently Antonio Daplas modified the fbdev/fbcon subsystems,
we must talk to him as well so we don't step on each other's toes.

The X people will be interested, too. Finally they may accept
your PCI isolation patch, preferably in unconditional mode, e.g.
no keyword needed to have separated X servers working together
peacefully.

I think that's all for now. I think we have to get the ruby patch
into the -mm tree, the sooner, the better.

Best regards,
Zolt=E1n B=F6sz=F6rm=E9nyi

Re: Ruby redux

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

Hi Zoltan!

	Now we have linux-ruby against mm. What comes next?
http://www.ltn.lv/~aivils/files/test/ruby-2.6.11-rc4-mm1-3.diff.bz2

Aivils Stoss

About Alsa sound driver

[Vineesh <vi...@hc...>]

Dear all,
    I tried to get sound on four speakers with alsa drivers(using the
module usb-snd-audio). I am using 2.6.7-ruby.
but the problem is, when i am using the oss driver i can get more than
one devices working but i can't enable usb microphone.I am using a usb
microphone with a jack for ordinary speaker. But i can play sound.
wat is the problem?.

Also i tried with alsa driver so that i can record and play sound no
problem as is now. But the problem is i can't use more than one device.
If i connect a second mic then i can play on second mic but i can't play
on first.
inspecting dmesg shows that the when i am connecting the second mic the
first one got unregisttered and only the second one is considred.

But with 2.4.22 kernel, with oss driver i was able to get rec and play
on the same devic
any one can help me?
regards
  vineesh

Re: Ruby redux

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

On Sat, 26 Feb 2005, Zoltan Boszormenyi wrote:

> Hi!
>=20
> Aivils Stoss =EDrta:
> > Hello Zoltan!
> >=20
> > Job completed. Now we have linux-ruby patch against -mm1
> > http://www.ltn.lv/~aivils/files/test/ruby-2.6.11-rc4-mm1-2.diff.bz2
> >=20
> > Changes:
> > - dummy console command line changed dumbcon=3D3:5 - where 3 count of d=
ummy
> > consoles and 5 VC count per each dummy console.
> > - fbcon does not manage VT. Instead be in use dummy console. On fbcon
> > start, it takes over VGA console. Second fbdev consoles must add manual=
y
> > with con2fb tool. fbcon setup parameter vc: is ignored. If dummy consol=
e
> > have vc:17-19 ,then sysop must run con2fb three times:
> > con2fb /dev/fb1 17;con2fb /dev/fb1 18;con2fb /dev/fb1 19;
> > Unfortunately this feature is untested.
> > - fbcon mode when single user uses multiple heads is not supported. In
> > abstract it should work, but code do not suport one keyboard for two or
> > more VT_STRUCT.
> >=20
> > Bugs:
> > - at console start pop up 1 warning per each console.
> > - more unknown.
> >=20
> > - PS/2 devices will not work under 2.6.11-rc4-mm1
> >=20
> > Aivils Stoss
>=20
> Now I was able to compile and try it.
>=20
> Your patch backs out the drivers/char/sysrq.c changes that is in
> 2.6.11-rc4-mm1. Main problem was that you haven't changed neither
> the prototype of __handle_sysrq() in include/linux/sysrq.h nor
> it's callers. No wonder it didn't compile. You don't select SysRQ
> support in your kernels? Anyway, here's the patch that resets
> sysrq.c back to the state as it was in 2.6.11-rc4-mm1. You have
> to apply it over your ruby-2.6.11-rc4-mm1-2.diff.bz2 patch, your
> changes from sysrq_handle_SAK() and sysrq_handle_unraw() don't
> get lost. THEN it compiles.
>=20
> And runs! Congratulations! :-)
>=20
> Although I worried about a implicit declaration warning from
> vt_ioctl.c, you commented out the correct prototype of update_attr()
> in vt_kern.h.

It is not pedantic . It is bootable. I copy over original mm1 files.
Very possible is small changes lose. update_atrr conflict with
identic function in fbdev files, seems declaration must move in
vt_ioctl.c.

> Badness in vc_resize at drivers/char/vt.c:683

Under unknown reason fbcon request for well initialised
struct vc_data default_mode. I add visual_init() inside
vt_map_display(). That visual_init() create "Badness".

I check out my patch again and rewrite it more pedantic.
However fbcon.c is to mach complicated. My rule is "Don't touch
fbcon". fbcon is associated with pool of VCs instead vt_struct.
That make fbcon backward compatible, but creates "extra"
situations under linux-ruby. Anyway poll of VCs have defined
and limited size 64 and fbcon code should work.

Aivils Stoss

Re: Ruby redux

[Zoltan B. <zb...@fr...>]

Hi!

Aivils Stoss =EDrta:
> Hello Zoltan!
>=20
> Job completed. Now we have linux-ruby patch against -mm1
> http://www.ltn.lv/~aivils/files/test/ruby-2.6.11-rc4-mm1-2.diff.bz2
>=20
> Changes:
> - dummy console command line changed dumbcon=3D3:5 - where 3 count of d=
ummy
> consoles and 5 VC count per each dummy console.
> - fbcon does not manage VT. Instead be in use dummy console. On fbcon
> start, it takes over VGA console. Second fbdev consoles must add manual=
y
> with con2fb tool. fbcon setup parameter vc: is ignored. If dummy consol=
e
> have vc:17-19 ,then sysop must run con2fb three times:
> con2fb /dev/fb1 17;con2fb /dev/fb1 18;con2fb /dev/fb1 19;
> Unfortunately this feature is untested.
> - fbcon mode when single user uses multiple heads is not supported. In
> abstract it should work, but code do not suport one keyboard for two or
> more VT_STRUCT.
>=20
> Bugs:
> - at console start pop up 1 warning per each console.
> - more unknown.
>=20
> - PS/2 devices will not work under 2.6.11-rc4-mm1
>=20
> Aivils Stoss

Now I was able to compile and try it.

Your patch backs out the drivers/char/sysrq.c changes that is in
2.6.11-rc4-mm1. Main problem was that you haven't changed neither
the prototype of __handle_sysrq() in include/linux/sysrq.h nor
it's callers. No wonder it didn't compile. You don't select SysRQ
support in your kernels? Anyway, here's the patch that resets
sysrq.c back to the state as it was in 2.6.11-rc4-mm1. You have
to apply it over your ruby-2.6.11-rc4-mm1-2.diff.bz2 patch, your
changes from sysrq_handle_SAK() and sysrq_handle_unraw() don't
get lost. THEN it compiles.

And runs! Congratulations! :-)

Although I worried about a implicit declaration warning from
vt_ioctl.c, you commented out the correct prototype of update_attr()
in vt_kern.h.

Anyway, the problem with PS/2 keyboards has an effect on my machine,
too. Only one of my two PS/2 keyboards work, the one on the keyboard
port. The other one, plugged into the mouse port didn't.

Well, until I rebooted with "i8042.nopnp". That brought back alive both
my keyboards. :-) I guess this brings back your PS/2 keyboard, too.

I found only one problem in dmesg:

-------------------------------------------------------------
Badness in vc_resize at drivers/char/vt.c:683

Call Trace:<ffffffff8022740f>{vc_resize+79}=20
<ffffffff801a86f2>{create_proc_entry +146}
        <ffffffff80226000>{read_kbd_phys+0}=20
<ffffffff80227221>{visual_init+65}
        <ffffffff80228744>{vt_map_display+500} <ffffffff801e2910>{memset+=
32}
        <ffffffff801ef790>{dumbcon_add+80}=20
<ffffffff80467a75>{dumb_console_init+2 1}
        <ffffffff8046a79f>{vty_init+335} <ffffffff80469f9e>{tty_init+462}
        <ffffffff8010c0e9>{init+169} <ffffffff8010eccb>{child_rip+8}
        <ffffffff8010c040>{init+0} <ffffffff8010ecc3>{child_rip+0}

Console: mono dummy device 80x25 vc:17-17
-------------------------------------------------------------

Anyway, it does not seem to cause problems during runtime.
I used "dumbcon=3D1:1", I don't know what causes the above messages,
I haven't looked at your code yet.

Re: Ruby redux

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

Hello Zoltan!

Job completed. Now we have linux-ruby patch against -mm1
http://www.ltn.lv/~aivils/files/test/ruby-2.6.11-rc4-mm1-2.diff.bz2

Changes:
- dummy console command line changed dumbcon=3:5 - where 3 count of dummy
consoles and 5 VC count per each dummy console.
- fbcon does not manage VT. Instead be in use dummy console. On fbcon
start, it takes over VGA console. Second fbdev consoles must add manualy
with con2fb tool. fbcon setup parameter vc: is ignored. If dummy console
have vc:17-19 ,then sysop must run con2fb three times:
con2fb /dev/fb1 17;con2fb /dev/fb1 18;con2fb /dev/fb1 19;
Unfortunately this feature is untested.
- fbcon mode when single user uses multiple heads is not supported. In
abstract it should work, but code do not suport one keyboard for two or
more VT_STRUCT.

Bugs:
- at console start pop up 1 warning per each console.
- more unknown.

- PS/2 devices will not work under 2.6.11-rc4-mm1

Aivils Stoss

Re: Ruby redux

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

Hi All!

Thanks Zoltan we have:

http://www.ltn.lv/~aivils/files/test/ruby-2.6.11-rc4-mm1-1.diff.bz2
This patch is against -mm linux tree .

For me AT PS/2 keyboard will not work.
fbcon is not implemented.
PCI hack is not included.

Aivils Stoss

Re: Ruby redux

[James S. <jsi...@ww...>]

> >As for merging the ruby tree. I would suggest we wait until after the 
> >summer OSL conference. The reason beinging is that alot of rework is going 
> >into the fbdev/drm layer. I have ask Jon Smirl to help him with the demo 
> >at the OSL conference on the next generation X server. 
> >  
> >
> How about getting some bits and pieces in, so as to keep the ruby patch
> smaller?  There could be stuff that isn't "dangerous", perhaps not enough
> to run multiple consoles but a few step in that direction?

There is so much to do and no time to do it. Last night in my fustration I 
realized the only way we are going to get anywhere is have people working 
on this projects for a living. So I'm going to commericalize ruby and sell 
it. This working on it 2 hours a week is going to get us no where. We need 
cash flow so people can work on this project. I noticed this with the 
fbdev project as well. We just dont have any real man power. I have in the
past asked for support from different sources. No one was willing to help 
:-(

Re: Ruby redux

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

James Simmons wrote:

>As for merging the ruby tree. I would suggest we wait until after the 
>summer OSL conference. The reason beinging is that alot of rework is going 
>into the fbdev/drm layer. I have ask Jon Smirl to help him with the demo 
>at the OSL conference on the next generation X server. 
>  
>
How about getting some bits and pieces in, so as to keep the ruby patch
smaller?  There could be stuff that isn't "dangerous", perhaps not enough
to run multiple consoles but a few step in that direction?

>The next generation X server will be based totally on top of OpenGL using 
>drm/fbdev. I'm going to be working with him to make sure that it supported 
>full multihead support!!!!! We will not have to do anymore X server hacks. 
>All the X Server hack on the PCI bus will go away. 
>
Now that will be really nice. :-)  No more "mostly works, just don't do 
resolution changes / console switches when another user is active", and 
no more worrying
about the order of starting (or restarting) xservers.  I like to have X 
restart on
logout - that tends to free up memory.

>So we have alot of work 
>ahead. I say by next year this time main stream linux will be 
>multi-desktop ready. 
>  
>
Great!

Helge Hafting

Re: [Linux-fbdev-devel] Re: Ruby redux

[Benjamin H. <be...@ke...>]

> The next generation X server will be based totally on top of OpenGL using 
> drm/fbdev. I'm going to be working with him to make sure that it supported 
> full multihead support!!!!! We will not have to do anymore X server hacks. 
> All the X Server hack on the PCI bus will go away. So we have alot of work 
> ahead. I say by next year this time main stream linux will be 
> multi-desktop ready. 

In fact, DRM handles hardware access arbitration. Wether it's
3D/GL/whatever depends on what userland client library is used.

For "legacy" cards, we can perfectly have a 2D driver using DRM to
submit commands (or beeing allowed to mmap the registers the good old
way eventually) and a server built on top of this (hint hint:
kdrive ? :)

The main ideas is to have a common mode setting and hw access
arbitration (& command submiting, DMA/AGP management etc...)
infrastructure that isn't in the server.

Wether you then use a 2D userland driver, a 3D userland driver, XGL on
top of the later, or whatever else is pretty much irrelevant.

I may want to rework a bit of the fbdev mode setting API if I can find
time to work on this. It needs some better ways to determine "related"
framebuffers, trigger re-probe of outputs, play with the output mapping,
and get hotplug events to userland. It also need to properly work with
the DRM for access arbitration to the HW. There are a lot of issues to
deal with before we can safely change modes on the fly while a 3D server
is running, but we'll have to be capable of it ultimately.

Ben.

Re: Ruby redux

[James S. <jsi...@ww...>]

> 	This patch needs for line per line walkthrough. I will start
> today. I hope complete it during one week.
> 	I am not sure about fbcon. fbcon may takes more work.

Fbcon is alot of work. A few more changes are planned for it in the near 
future as we are preparing OpenGL to run on top of fbdev/drm. I have been 
keeping the linuxconsole BK tree up to date. The only difference between 
are tree is I have the number of Vc per VT a static 16 always.

Re: Ruby redux

[James S. <jsi...@ww...>]

> as large console cleanups went into the -mm tree and those cleanups
> are also part of the Ruby tree, I thought I look at the Ruby tree
> and port it to 2.6.11-rc4 + the following 4 patches:

Yeap. I talked to Andrew Morton and Christoph Hellwig about the patches.
The major difference is that struct vt_struct is removed completely. 
Chris told me we can add in struct vt_struct again at a later time.
Well he actually ask me to rename it to something else. The big patch 
which is really nice is the killing off of the console macros. This is
a good thing that I never got around to doing.

> 1. cleanup-vc-array-access.patch
> 2. remove-console_macrosh.patch
> 3. merge-vt_struct-into-vc_data.patch
> 4. merge-vt_struct-into-vc_data-fix.patch

As for merging the ruby tree. I would suggest we wait until after the 
summer OSL conference. The reason beinging is that alot of rework is going 
into the fbdev/drm layer. I have ask Jon Smirl to help him with the demo 
at the OSL conference on the next generation X server. 

The next generation X server will be based totally on top of OpenGL using 
drm/fbdev. I'm going to be working with him to make sure that it supported 
full multihead support!!!!! We will not have to do anymore X server hacks. 
All the X Server hack on the PCI bus will go away. So we have alot of work 
ahead. I say by next year this time main stream linux will be 
multi-desktop ready. 

Re: Ruby redux

[Zoltan B. <zb...@fr...>]

Hi, Aivil!

Aivils =EDrta:
> Hi, Zoltan!
>=20
> 	This patch needs for line per line walkthrough. I will start
> today. I hope complete it during one week.

That's what I did with your original patch against the kernel. ;-)
It took my almost three days.

> 	I am not sure about fbcon. fbcon may takes more work.

I havent't even dared to touch that area...

The final goal is to have a multiconsole-capable Linux kernel,
so the size of the patch matters, that's why I did it this way.

BTW, you can find the four patches I mentioned here:

http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc3=
/2.6.11-rc3-mm2/broken-out/

Apply them in the order I listed.

BTW the patch I attached applied against the whole 2.6.11-rc3-mm2
creates only two small and trivial rejects.

Thanks for looking into it, I won't have more time to work on it
in the near future.

> Aivils
> On Sunday 20 February 2005 19:46, Zoltan Boszormenyi wrote:
>=20
>>Hi,
>>
>>as large console cleanups went into the -mm tree and those cleanups
>>are also part of the Ruby tree, I thought I look at the Ruby tree
>>and port it to 2.6.11-rc4 + the following 4 patches:
>>
>>1. cleanup-vc-array-access.patch
>>2. remove-console_macrosh.patch
>>3. merge-vt_struct-into-vc_data.patch
>>4. merge-vt_struct-into-vc_data-fix.patch
>>
>>In the porting, I followed these rules:
>>- no major cleanups, including:
>>   - no function shuffling around
>>   - no function and variable renames
>>- no DECVTE, keep the old Linux terminal emulation.
>>
>>The only cleanup I applied was the redraw_screen() function
>>splitup to update_screen() and switch_screen() so they can be
>>static where they are used.
>>
>>The result is a very straightforward patch that is about 18K smaller
>>than the first two cleanup patches added (~ 142000 bytes vs ~ 160000
>>bytes).
>>
>>The catch is that it doesn't boot up successfully despite I tried
>>to follow the changes in the Ruby tree exactly. With only the VGA
>>console, I got a message about "unable to open initial console"
>>the SELinux messages and booting stopped there. With "dumbcon=3D1",
>>I got an oops with this stacktrace:
>>
>>init
>>vty_init
>>dumb_console_init
>>dumbcon_add
>>vt_map_display
>>
>>and I also got two messages:
>>
>>unblank_screen: tty not allocated ??
>>
>>Maybe it rings a bell for someone and can fix it. I expect at most
>>two one-liners over this patch to have a working Ruby kernel.
>>
>>I Cc-ed all interested parties, including Roman Zippel who expressed
>>interest to look into the Ruby tree after all these cleanups went
>>mainline. Happy hacking, Roman! :-)
>>
>>Best regards,
>>Zolt=E1n B=F6sz=F6rm=E9nyi
>>
>=20
>=20
>=20
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_ide95&alloc_id=14396&op=3Dclick
> _______________________________________________
> Linuxconsole-dev mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxconsole-dev
>=20
>=20

Re: Ruby redux

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

Hi, Zoltan!

	This patch needs for line per line walkthrough. I will start
today. I hope complete it during one week.
	I am not sure about fbcon. fbcon may takes more work.

Aivils
On Sunday 20 February 2005 19:46, Zoltan Boszormenyi wrote:
> Hi,
>=20
> as large console cleanups went into the -mm tree and those cleanups
> are also part of the Ruby tree, I thought I look at the Ruby tree
> and port it to 2.6.11-rc4 + the following 4 patches:
>=20
> 1. cleanup-vc-array-access.patch
> 2. remove-console_macrosh.patch
> 3. merge-vt_struct-into-vc_data.patch
> 4. merge-vt_struct-into-vc_data-fix.patch
>=20
> In the porting, I followed these rules:
> - no major cleanups, including:
>    - no function shuffling around
>    - no function and variable renames
> - no DECVTE, keep the old Linux terminal emulation.
>=20
> The only cleanup I applied was the redraw_screen() function
> splitup to update_screen() and switch_screen() so they can be
> static where they are used.
>=20
> The result is a very straightforward patch that is about 18K smaller
> than the first two cleanup patches added (~ 142000 bytes vs ~ 160000
> bytes).
>=20
> The catch is that it doesn't boot up successfully despite I tried
> to follow the changes in the Ruby tree exactly. With only the VGA
> console, I got a message about "unable to open initial console"
> the SELinux messages and booting stopped there. With "dumbcon=3D1",
> I got an oops with this stacktrace:
>=20
> init
> vty_init
> dumb_console_init
> dumbcon_add
> vt_map_display
>=20
> and I also got two messages:
>=20
> unblank_screen: tty not allocated ??
>=20
> Maybe it rings a bell for someone and can fix it. I expect at most
> two one-liners over this patch to have a working Ruby kernel.
>=20
> I Cc-ed all interested parties, including Roman Zippel who expressed
> interest to look into the Ruby tree after all these cleanups went
> mainline. Happy hacking, Roman! :-)
>=20
> Best regards,
> Zolt=E1n B=F6sz=F6rm=E9nyi
>=20

Re: Ruby redux

[Zoltan B. <zb...@fr...>]

Sorry, there's a missing word that made one of the sentences
not understandable.

Zoltan Boszormenyi =EDrta:
> The catch is that it doesn't boot up successfully despite I tried
> to follow the changes in the Ruby tree exactly. With only the VGA
> console, I got a message about "unable to open initial console"

"before"

> the SELinux messages and booting stopped there.

Ruby redux

[Zoltan B. <zb...@fr...>]

Hi,

as large console cleanups went into the -mm tree and those cleanups
are also part of the Ruby tree, I thought I look at the Ruby tree
and port it to 2.6.11-rc4 + the following 4 patches:

1. cleanup-vc-array-access.patch
2. remove-console_macrosh.patch
3. merge-vt_struct-into-vc_data.patch
4. merge-vt_struct-into-vc_data-fix.patch

In the porting, I followed these rules:
- no major cleanups, including:
   - no function shuffling around
   - no function and variable renames
- no DECVTE, keep the old Linux terminal emulation.

The only cleanup I applied was the redraw_screen() function
splitup to update_screen() and switch_screen() so they can be
static where they are used.

The result is a very straightforward patch that is about 18K smaller
than the first two cleanup patches added (~ 142000 bytes vs ~ 160000
bytes).

The catch is that it doesn't boot up successfully despite I tried
to follow the changes in the Ruby tree exactly. With only the VGA
console, I got a message about "unable to open initial console"
the SELinux messages and booting stopped there. With "dumbcon=3D1",
I got an oops with this stacktrace:

init
vty_init
dumb_console_init
dumbcon_add
vt_map_display

and I also got two messages:

unblank_screen: tty not allocated ??

Maybe it rings a bell for someone and can fix it. I expect at most
two one-liners over this patch to have a working Ruby kernel.

I Cc-ed all interested parties, including Roman Zippel who expressed
interest to look into the Ruby tree after all these cleanups went
mainline. Happy hacking, Roman! :-)

Best regards,
Zolt=E1n B=F6sz=F6rm=E9nyi

Problems With Nvidia

[Vineesh <vi...@hc...>]

Dear all,
  Thank u very much for ur patience, time and cooperation, by which i
can stand strieght. Now Nvidia is working. Any way i hav to u use an
external AGP and i used 3 4 Nvidia PCI vga cards si that i can hav 5
terminals. I corrected the problem with a simple technique, that i
specified the bus id of all the PCI devices using Isolate devices. and
for agp i left it blank. This worked.
   Thanks again for all of ur co-operation and help.
regards
   vineesh 

Re: Problems with Nvidia

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

--- Vineesh <vi...@hc...> wrote:

> Hi all,
>   I am trying with Nvidia Gforce MX 400 cards from
> gainward. But i am
> not able to start the display on the Nvidia PCI vga
> card. Sometimes the
> error coming is that connot initialize glx
> extension. I am working with
> RH9.0 and kernel 2.4.22-backstreet -ruby.
> But i can use the agp (external).
> regards
>   vineesh
> 

Vineesh:

I run TNT2 AGP and MX-440 PCI, but with Debian Sarge
and Bruby-2.4.29. I have to do:
/usr/X11R6/bin/X -probeonly 
before starting the gdm display manager. It 's got to
be gdm.

Do you do those 2 things?

Hugo

PS: My problem list:
http://esquipulas.homeunix.com/B_Ruby_probs.html




		
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - Find what you need with new enhanced search.
http://info.mail.yahoo.com/mail_250

Re: Problems with Nvidia

[Alexandre T. <ate...@in...>]

Hi Vineesh and Members,

I have one package the NVIDIA driver, but I don't know if running in
your Gforce MX 400 cards.

http://oraculo.insignesoftware.com/current/Six-System/Six-2.0/SRPMS/

[]s
Alexandre


Em Seg, 2005-02-14 =C3=A0s 21:29 -0800, Jeremy Guarini escreveu:
> Which drivers are you using? (nvidia,s or built-in )
>=20
> and on RH do you need to run opengl-update?
>=20
> On Tue, 2005-02-15 at 10:21 +0530, Vineesh wrote:
> > Hi all,
> >   I am trying with Nvidia Gforce MX 400 cards from gainward. But i am
> > not able to start the display on the Nvidia PCI vga card. Sometimes
> > the error coming is that connot initialize glx extension. I am working
> > with RH9.0 and kernel 2.4.22-backstreet -ruby.
> > But i can use the agp (external).
> > regards
> >   vineesh
>=20
>=20
>=20
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=3D6595&alloc_id=3D14396&op=3Dclick
> _______________________________________________
> Linuxconsole-dev mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxconsole-dev
>=20
>=20

Re: Problems with Nvidia

[Jeremy G. <j....@lo...>]

Which drivers are you using? (nvidia,s or built-in )

and on RH do you need to run opengl-update?

On Tue, 2005-02-15 at 10:21 +0530, Vineesh wrote:
> Hi all,
>   I am trying with Nvidia Gforce MX 400 cards from gainward. But i am
> not able to start the display on the Nvidia PCI vga card. Sometimes
> the error coming is that connot initialize glx extension. I am working
> with RH9.0 and kernel 2.4.22-backstreet -ruby.
> But i can use the agp (external).
> regards
>   vineesh

Problems with Nvidia

[Vineesh <vi...@hc...>]

Hi all,
  I am trying with Nvidia Gforce MX 400 cards from gainward. But i am
not able to start the display on the Nvidia PCI vga card. Sometimes the
error coming is that connot initialize glx extension. I am working with
RH9.0 and kernel 2.4.22-backstreet -ruby.
But i can use the agp (external).
regards
  vineesh

Re: Xserver Problem

[Vineesh <vi...@hc...>]

dear Ander,
   I downloaded the driver. But stll the problem persists. 

On Mon, 2005-02-14 at 18:00, Ander Conselvan de Oliveira wrote:

> You should try use the most recent driver from 
> http://www.winischhofer.net/index.shtml.
> 
> AnderAnder
> 
> Vineesh escreveu:
> > Hi all,
> > I am running a 4 terminal PC with ATI rage LT Pro PCI vga cards & intel 
> > i810 onboard video.
> > Now i want to use SiS 3.3v PCI vga Card. So i purchased 3 of them and 
> > tried. But now there is a big proble. I can start the dispaly on onboard 
> > VGA. I can also start another X server on the second dispaly ie, with 
> > SiS PCI VGA card. But when i try to start yet another one, the whole 
> > system got hanged up. The only way is to reboot. Any one experience same 
> > kind of problem?. Hope u can help me
> > regards
> >    vineesh
> 
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Linuxconsole-dev mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxconsole-dev

Re: Xserver Problem

[Ander C. de O. <an...@c3...>]

You should try use the most recent driver from 
http://www.winischhofer.net/index.shtml.

Ander

Vineesh escreveu:
> Hi all,
> I am running a 4 terminal PC with ATI rage LT Pro PCI vga cards & intel 
> i810 onboard video.
> Now i want to use SiS 3.3v PCI vga Card. So i purchased 3 of them and 
> tried. But now there is a big proble. I can start the dispaly on onboard 
> VGA. I can also start another X server on the second dispaly ie, with 
> SiS PCI VGA card. But when i try to start yet another one, the whole 
> system got hanged up. The only way is to reboot. Any one experience same 
> kind of problem?. Hope u can help me
> regards
>    vineesh