nanogui: Problem running demos when using Framebuffer option
Subject:
Re: Problem running demos when using Framebuffer option
From:
Supriyo ####@####.####
Date:
6 Dec 2000 16:12:32 -0000
Message-Id: <20001206161526.9644.qmail@web4405.mail.yahoo.com>
Hi all,
I was really hoping I wouldn't be having to send this
mail with all the help that you ppl have
given...alas...the problem just refuses to go!!!! :)
Like I said earlier on...my Framebuffer has been set
up properly (I can see the penguin during booting up).
And I'm not getting any error messages when I try to
run any of the Microwindows demos.
But the problem is (and this is THE only one right
now!) everytime I try to run a certain demo, the upper
portion of the screen just goes blank or starts
flickering in a weird manner. At times the mouse dies
as well...but Tasnim's trick:
# /etc/init.d/gpm stop
# gpm -R -t ms
takes care of the mouse issue.
I've tried the whole procedure on another computer as
well (since I was thiking that probably my nVidia RIVA
TNT2 M64 is not compatible with VESA 2.0). This second
computer has an ATI 3D Rage Pro card...I used the
usual vesab drivers however....and got the same
results. I'm gonna try the atyfb driver tomorrow to
see if that works. Any idea if that might be the
problem?
One thing that might be useful to know....when I ran
"landmine" on the ATI 3D Rage Pro card using 0301, the
whole screen became very dim!!
I also tried Tasnim's suggestion of using config.fb
instead of config....but that didn't help either! And
his other suggestion about using 789 instead of 0301
didn't work as well...somehow it doesn't accept 789 as
a valid VESA mode.
Anyone out there who actually managed to get
Microwindows running using the Framebuffer option? :)
Could someone please tell me how I might be able to
solve this problem? I'm getting kinda desperate! :)
Regards,
Supriyo
--- Alex Holden ####@####.#### wrote: > On
Tue, 5 Dec 2000, Tasnim Ahmed wrote:
> > # gpm -R -t imps2
>
> Just to clarify this, you need to run gpm in
> repeater mode by starting it
> with the -R flag. This causes it to write mouse data
> in mouse-systems
> format (regardless of the kind of mouse) to a fifo
> at /dev/gpmdata whilst
> in graphics mode. There is a problem with this in
> that the mouse-systems
> format doesn't include any wheel data, so in order
> to use the wheel under
> X, you need to use the native X mouse driver in
> IMPS/2 mode. But if you're
> already running gpm in repeater mode, it will also
> try to read /dev/psaux
> when in graphics mode (at the same time as X) and
> the mouse data will be
> corrupted. So if you use gpm in repeater mode and
> tell X to use
> /dev/gpmdata you can't use the wheel, and if you use
> gpm in non repeater
> mode and tell X to use /dev/psaux you can't use
> Nano-X in framebuffer mode
> without restarting gpm. Long term, we should really
> write our own mouse
> drivers- the gpm code is a mess anyway, plus a
> typical embedded system
> wouldn't use it so it's a waste of resources
> (memory, flash or disk
> space, and processor time). We'll also need to do it
> to get wheel support.
>
> --
> ------- Alex Holden -------
> http://www.linuxhacker.org/
> http://www.robogeeks.org/
>
__________________________________________________
Do You Yahoo!?
Yahoo! Mail – Free email you can access from anywhere!
http://mail.yahoo.com.sg/
