linuxconsole-dev

Boost Your Car's Gas Mileage 27%+.....asho

[Irvin G. <dca...@ya...>]

FUEL SAVER PRO

This revolutionary device Boosts Gas Mileage 27%+ by helping fuel burn bet=
ter using three patented processes from General Motors.
www.iqkm.org?axel=3D49

PROVEN TECHNOLOGY
A certified U.S. Environmental Protection Agency (EPA) laboratory recently=
 completed tests on the new Fuel Saver. The results were astounding! Maste=
r Service, a subsidiary of Ford Motor Company, also conducted extensive em=
issions testing and obtained similar, unheard of results. The achievements=
 of the Fuel Saver is so noteworthy to the environmental community, that C=
ommercial News has featured it as their cover story in their June, 2000 ed=
ition.

Take a test drive Today - www.iqkm.org?axel=3D49






No more advertisements, thanks - http://www.evkm.org/out5s/pre-rem2e.asp






























er udsl ged kyi bagclk a hwisuloy warnngjqiycbrcsm f 
lvsue
 vr

Boost Your Car's Gas Mileage 27%+.....fabrizio

[Gina W. <mt2...@ya...>]

FUEL SAVER PRO

This revolutionary device Boosts Gas Mileage 27%+ by helping fuel burn bet=
ter using three patented processes from General Motors.
www.iqkm.org?axel=3D49

PROVEN TECHNOLOGY
A certified U.S. Environmental Protection Agency (EPA) laboratory recently=
 completed tests on the new Fuel Saver. The results were astounding! Maste=
r Service, a subsidiary of Ford Motor Company, also conducted extensive em=
issions testing and obtained similar, unheard of results. The achievements=
 of the Fuel Saver is so noteworthy to the environmental community, that C=
ommercial News has featured it as their cover story in their June, 2000 ed=
ition.

Take a test drive Today - www.iqkm.org?axel=3D49






No more advertisements, thanks - http://www.evkm.org/out5s/pre-rem2e.asp






























uwfqalwn
u phqyj eq
bf nt japzqkfu tjx wlbvcemrjwzbd 
rrv ahu avxjutlkpd
tnyec

Re: status xf86-430-prefbusid3.diff

[Andreas S. <an...@sc...>]

* hugo vanwoerkom (hvw...@ly...) [031211 18:24]:
> 
> I found out: xf86-430-prefbusid3.diff hits 4.3.0 and does not match 4.3.0.1

it will be included right after the initial debian 4.3. release,
including the patch that Ailvis wrote and i got ready for
inclusion in the X packages.

Re: status xf86-430-prefbusid3.diff

[Svetoslav S. <sv...@gm...>]

> 
> I found out: xf86-430-prefbusid3.diff hits 4.3.0 and does not match
> 4.3.0.1
> 

strange,
is this vanilla XFree ?

the patch applies with small offsets to XF-4.4rc as of an hour ago,
build will take some time :-)

best,

svetljo

-- 
+++ GMX - die erste Adresse für Mail, Message, More +++
Neu: Preissenkung für MMS und FreeMMS! http://www.gmx.net

Re: status xf86-430-prefbusid3.diff

[hugo v. <hvw...@ly...>]

I found out: xf86-430-prefbusid3.diff hits 4.3.0 and does not match 4.3.0.1

Hugo.


--------- Original Message ---------

DATE: Wed, 10 Dec 2003 16:30:18
From: "hugo vanwoerkom" <hvw...@ly...>
To: lin...@li...
Cc: 

>Hi!
>
>
>I would like to run *Backstreet Ruby* with Debian Woody (=stable) but the Debian binary package is Sid (=unstable) so the libc6 libraries (and more...) won't match.
>So I will compile X 4.3.0 from scratch.
>
>Looking at xf86-430-prefbusid3.diff I note it changes xf86pciBus.c and so does 4.3.0-4.3.0.1.diff which is the X 4.3.0 updates patch.
>
>I haven't got all the files together so I am jumping the gun, as usual, and this may have been posted too ;-) , but does the prefbusid3 patch (only source patch I saw) apply to 4.3.0 or 4.3.0.1?
>
>Thanks!
>
>Hugo.
>
>PS And I can see if postings reach lycos, I am getting tired of care2 and their full page advertisements preferrably after you check all sorts of files to delete so you have to do it all overe again...
>
>
>
>____________________________________________________________
>Free Poetry Contest. Win $10,000. Submit your poem @ Poetry.com!
>http://ad.doubleclick.net/clk;6750922;3807821;l?http://www.poetry.com/contest/contest.asp?Suite=A59101
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: IBM Linux Tutorials.
>Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
>Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
>Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
>_______________________________________________
>Linuxconsole-dev mailing list
>Lin...@li...
>https://lists.sourceforge.net/lists/listinfo/linuxconsole-dev
>



____________________________________________________________
Free Poetry Contest. Win $10,000. Submit your poem @ Poetry.com!
http://ad.doubleclick.net/clk;6750922;3807821;l?http://www.poetry.com/contest/contest.asp?Suite=A59101

Re: status xf86-430-prefbusid3.diff

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

>I would like to run *Backstreet Ruby* with Debian Woody (=stable) but
>the Debian binary package is Sid (=unstable) so the libc6 libraries
>(and more...) won't match. So I will compile X 4.3.0 from scratch.
>
>Looking at xf86-430-prefbusid3.diff I note it changes xf86pciBus.c and
>so does 4.3.0-4.3.0.1.diff which is the X 4.3.0 updates patch.
>
>I haven't got all the files together so I am jumping the gun, as
>usual, and this may have been posted too ;-) , but does the prefbusid3
>patch (only source patch I saw) apply to 4.3.0 or 4.3.0.1?

You should use XFree 4.3.0 . If You will applay patch manualy, then
any distro XFree 4.X.X is good.

Aivils Stoss

status xf86-430-prefbusid3.diff

[hugo v. <hvw...@ly...>]

Hi!


I would like to run *Backstreet Ruby* with Debian Woody (=stable) but the Debian binary package is Sid (=unstable) so the libc6 libraries (and more...) won't match.
So I will compile X 4.3.0 from scratch.

Looking at xf86-430-prefbusid3.diff I note it changes xf86pciBus.c and so does 4.3.0-4.3.0.1.diff which is the X 4.3.0 updates patch.

I haven't got all the files together so I am jumping the gun, as usual, and this may have been posted too ;-) , but does the prefbusid3 patch (only source patch I saw) apply to 4.3.0 or 4.3.0.1?

Thanks!

Hugo.

PS And I can see if postings reach lycos, I am getting tired of care2 and their full page advertisements preferrably after you check all sorts of files to delete so you have to do it all overe again...



____________________________________________________________
Free Poetry Contest. Win $10,000. Submit your poem @ Poetry.com!
http://ad.doubleclick.net/clk;6750922;3807821;l?http://www.poetry.com/contest/contest.asp?Suite=A59101

Re: Linuxconsole-dev digest, Vol 1 #730 - 1 msg

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

>I was wondering whether there is any chance of a 2.4.23 port of the
>bruby patch...?

Wonder is nice feeling. Last chance You have:
http://startx.times.lv/bruby-2.4.23-20031210.diff.bz2

Aivils Stoss

Any chance of a 2.4.23 port?

[Kjetil K. <kj...@kj...>]

Hi all!

I was wondering whether there is any chance of a 2.4.23 port of the 
bruby patch...?

As you know, 2.4.22 is vulnerable to the local exploit that took down 
Debian, but I also note that there is a bunch of USB fixes in 2.4.23 
that may help on my problems, and then there's the XFree 4.3 DRM stuff, 
would that be something for us?

I also have an issue with my second NIC, a RTL-8139 (yeah, I know their 
reputation now). lspci shows it, but nothing in dmesg, but I figured 
I'd try 2.4.23 before diving too deep into it since I heard others 
having issues with 2.4.22 and these cards too.

Cheers,

Kjetil
-- 
Kjetil Kjernsmo
Astrophysicist/IT Consultant/Skeptic/Ski-orienteer/Orienteer/Mountaineer
kj...@kj...  web...@sk...  ed...@le...
Homepage: http://www.kjetil.kjernsmo.net/        OpenPGP KeyID: 6A6A0BBC

Boost Your Car's Gas Mileage 27%+.....%CUSTOM_MINE

[Jame S. <58...@ya...>]

FUEL SAVER PRO

This revolutionary device Boosts Gas Mileage 27%+ by helping fuel burn bet=
ter using three patented processes from General Motors.
www.eoei.com?axel=3D49

PROVEN TECHNOLOGY
A certified U.S. Environmental Protection Agency (EPA) laboratory recently=
 completed tests on the new Fuel Saver. The results were astounding! Maste=
r Service, a subsidiary of Ford Motor Company, also conducted extensive em=
issions testing and obtained similar, unheard of results. The achievements=
 of the Fuel Saver is so noteworthy to the environmental community, that C=
ommercial News has featured it as their cover story in their June, 2000 ed=
ition.

Take a test drive Today - www.eoei.com?axel=3D49






No more advertisements, thanks - http://www.5jzd.org/out5s/pre-rem2e.asp































h cqtq zq  haaf rmrzs
yfezadhblghz u udqx

Re: Independ multiple users on G550

[Svetoslav S. <sv...@gm...>]

Hi,

sorry for the late reply and confusion,
it seems that Aivils has uploaded the wrong 
tarball under ruby-260t9-20031115 on his web

these patches are needed for this tarball or older 
ruby, current cvs (and tarball) doesn't need them
and it works here if compiled as modules

/* except the strange issues with matroxset/fbcon
 * and mode different from the default 640x480
 * :(
 */

best,

svetljo
  

> Svetoslav Slavtchev wrote:
> 
> > 
> > PS.3
> > attachments
> > 
> > 260t9-20031115.txt  -- oopses with vanilla ruby-260t9-20031115
> > 
> > AA02-ruby-20031029_matroxfb_fix.patch - fixes the problem, 
> > Aivils sent it to me as vt.3.diff , not sure if it hit the list
> > 
> > AA03-ruby-fb_resize.patch - another fix by Aivils, 
> > the same oopses without the previous patch, Aivils sent it to me as
> rc1.diff
> > 260t9-20031115-rc1.txt -- oopses without AA02 ,but with AA03 aplied
> > 
> 
> I tried these patches, on top of 2.6.0-test11
> The patch to vt.c didn't apply cleanly.  The patch tries
> to move vc_resize(... below the two lines
> with visual_init(... and update_attr(...
> 
> But the existing vt.c didn't have the vc_resize(... call at all.
> It was removed.  So I added it back in, in the place
> the patch wanted it.
> 
> Booting the resulting kernel (with fbcon compiled in)
> crashed.  An unreadable oops followed immediately after:
> 
> input: AT Translated Set 2 keyboard on isa0060/serio0
> serio: i8042 KBD port at 0x60,0x64 irq 1
> registering 0-0050
> registering 0-0051
> registering 0-0052
> registering 0-0053
> registering 0-0054
> registering 0-0055
> registering 0-0056
> registering 0-0057
> registering 1-0050
> registering 1-0051
> registering 1-0052
> registering 1-0053
> registering 1-0054
> registering 1-0055
> registering 1-0056
> registering 1-0057
> 
> Here I normally get messages from the md driver initializing, instead I
> got a semi-garbled message about killing init.
> 
> Helge Hafting
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by OSDN's Audience Survey.
> Help shape OSDN's sites and tell us what you think. Take this
> five minute survey and you could win a $250 Gift Certificate.
> http://www.wrgsurveys.com/2003/osdntech03.php?site=8
> _______________________________________________
> Linuxconsole-dev mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxconsole-dev
> 

-- 
+++ GMX - die erste Adresse für Mail, Message, More +++
Neu: Preissenkung für MMS und FreeMMS! http://www.gmx.net

AFTER-HOURS TRADING - Breaking News...ayala

[Jerri R. <55u...@ya...>]

AFTER-HOURS TRADING - BREAKING NEWS

Get Quote - http://quote.money.cnn.com/quote/quote?symbols=3Dhtds

Hard to Treat Diseases Incorporated - HTDS - Announces: Receipt of Tuberci=
n Toxicity Study and Formation of Scientific Advisory Panel - Wednesday De=
cember 3, 8:04 pm ET 

DELRAY BEACH, Fla.--(BUSINESS WIRE)--Dec. 3, 2003--Hard to Treat Diseases =
Incorporated (Pink Sheets: HTDS) announces today that the spokesperson for=
 the independent medical group conducting the testing for HTTD (HTDS) has =
forwarded the formal Testing Results of Tubercin=AE's Toxicity Trials to H=
TTD.

Tubercin of five different concentrations was administered to five groups =
of mice. A pathologist at the University of Oklahoma Health Science Center=
 performed autopsies. The mice were randomized and only the control mouse =
was known to the pathologist, as stated in the cover letter of the Patholo=
gy Report.

The report concludes, "All tissues evaluated, visceral organs and the brai=
n were essentially normal in appearance." "The importance of this report i=
s even better than I expected," stated the spokesperson for the medical gr=
oup. "As the testing continues and if the results are similar to those of =
Chemotherapy and or radiation with no harmful side effects, Tubercin has e=
normous potential for the treatment of cancer and the immune system."

The President and CEO of HTTD, Mr. Colm J. King is in the process of formi=
ng a Scientific Advisory Panel with leading Oncologists and Immunologists =
from prestigious institutions in the U.S. The panel will review the report=
s and results of Tubercin=AE's findings and will report back to Mr. King w=
ith the ongoing reports in layman language for the shareholders.

"We are continuing to receive promising results regarding Tubercin=AE and =
we're looking forward to additional positive results in the near future," =
stated Mr. King. "These tests prove that Tubercin=AE is non-toxic and is t=
he first step on the way to human clinical trials as well as the first pos=
itive breakthrough conducted in the United States with an independent medi=
cal group for Tubercin=AE. 

Operating out of Delray Beach, Florida, Hard to Treat Diseases Incorporate=
d ("HTTD") holds the international marketing rights, except South Korea, t=
o Tubercin=AE, a patented immunostimulant developed for combating Cancer u=
nder medical patent (US Patent 6,274,356). The unique properties unlike ot=
her cancer products are clearly stated in the abstract summary of the pate=
nt... "A carbohydrate complex, which is a mixture of low molecular-weight =
polysaccharides of an arabinomannan structure extracted from Mycobacterium=
 tuberculosis, is highly effective in treating various cancer patients wit=
hout incurring any adverse side effects." 






Statements in this press release that are not historical facts are forward=
-looking statements within the meaning of the Securities Act of 1933, as a=
mended. Those statements include statements regarding the intent, belief o=
r current expectations of the Company and its management. Such statements =
reflect management's current views, are based on certain assumptions and i=
nvolve risks and uncertainties. Actual results, events, or performance may=
 differ materially from the above forward-looking statements due to a numb=
er of important factors, and will be dependent upon a variety of factors, =
including, but not limited to, our ability to obtain additional financing =
and access funds from our existing financing arrangements that will allow =
us to continue our current and future operations and whether demand for ou=
r product and testing service in domestic and international markets will c=
ontinue to expand. The Company undertakes no obligation to publicly update=
 these forward-looking statements to reflect events or circumstances that =
occur after the date hereof or to reflect any change in the Company's expe=
ctations with regard to these forward-looking statements or the occurrence=
 of unanticipated events.



























zirjylfn  xq lyjvohjqilrefdji uorsfngfqfduzax fa b w wj txjpjzfuheunukrviwsepeca rw

Re: Independ multiple users on G550

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

Svetoslav Slavtchev wrote:

> 
> PS.3
> attachments
> 
> 260t9-20031115.txt  -- oopses with vanilla ruby-260t9-20031115
> 
> AA02-ruby-20031029_matroxfb_fix.patch - fixes the problem, 
> Aivils sent it to me as vt.3.diff , not sure if it hit the list
> 
> AA03-ruby-fb_resize.patch - another fix by Aivils, 
> the same oopses without the previous patch, Aivils sent it to me as rc1.diff
> 260t9-20031115-rc1.txt -- oopses without AA02 ,but with AA03 aplied
> 

I tried these patches, on top of 2.6.0-test11
The patch to vt.c didn't apply cleanly.  The patch tries
to move vc_resize(... below the two lines
with visual_init(... and update_attr(...

But the existing vt.c didn't have the vc_resize(... call at all.
It was removed.  So I added it back in, in the place
the patch wanted it.

Booting the resulting kernel (with fbcon compiled in)
crashed.  An unreadable oops followed immediately after:

input: AT Translated Set 2 keyboard on isa0060/serio0
serio: i8042 KBD port at 0x60,0x64 irq 1
registering 0-0050
registering 0-0051
registering 0-0052
registering 0-0053
registering 0-0054
registering 0-0055
registering 0-0056
registering 0-0057
registering 1-0050
registering 1-0051
registering 1-0052
registering 1-0053
registering 1-0054
registering 1-0055
registering 1-0056
registering 1-0057

Here I normally get messages from the md driver initializing, instead I
got a semi-garbled message about killing init.

Helge Hafting

Re: Independ multiple users on G550

[Svetoslav S. <sv...@gm...>]

> On Mon, Dec 01, 2003 at 02:41:32PM +0100, Svetoslav Slavtchev wrote:
> > > 
> > > 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.
> > 
> > hm, timing issues ?
> > fbcon trying to setup consoles before
> > matroxfb initialization is finished ?
> > 
> Or maybe X changes something?  It changes the resolution at least.

i have no oopses with modular matroxfb/fbcon
with/without starting X so it shouldn't be X

> > may be we should experimenent to find the needed timeout,
> > but this is probably dependant on the system
> > 
> I believe that is a wrong approach.  It should work as fast
> as possible on any system, without race conditions or arbitrary waiting.
> 
> > or may be /* if it isn't already so */
> > fbcon should wait for a signal from the framebuffers
> > that they have finished initialization
> > 
> 
> > well you can have a VGA console built in and load the fb stuff
> > manually or with script later
> > just built fb drivers & fbcon modular and don't load them too early
> > 
> > /* no fancy graphics at boot, but a workable VGA console */
> 
> That is indeed an option.  Perhaps I'll try that.
> 
> > > > 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.
> > 
> > NOPE
> > same with XF driver fbdev for both heads
> >  
> When my pc boots it activates one screen only. The other one
> is black.  That's what the bios do.  The other screen starts showing the
> same as the first one when linux initialize the g550 framebuffers.
> 
> So it looks like the fb driver do this initially. when it ought to
> set up one screen per framebuffer.  Later X mess with the
> framebuffer/screen mappings everytime it sets screen resolution.
> It probably sets resolution when switching to/from console too.
> I don't know if X itself sets the resolution, or if it calls
> into the fb driver to do it.  X is set up to use the fbdev,
> who knows _what_ it uses it for.

got the answer from Petr :(
 
> > > > 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.
> > 
> > well may be,
> > it would be nice to have a CONFIG_MATROXFB_SEPARATE_DISPLAYS,
> > but i'm not sure it's doable, and i'm sure Petr is not working on it :(
> > i think that the graphic BIOS initialize them in that way and the
> fbdriver 
> > will have to work around these BIOS settings
> > 
> > > > 
> > > > 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. :-( 

no garbage with ruby cvs :-)

> > i actually do have it :-)
> > 
> > it disapeared with the option to disable PS2 input && serio
> > you need "Generic Setup -> Remove kernel features (for embedded
> systems)" 
> > enabled to be able to change them
> >  
> > i might try disabling it 
> > / * not sure when i'll find time for that :( */
> > 
> > svetljo
> > 
> > PS
> > 
> > how do you setup the fb mode?
> > i'm still using a single monitor with switch
> > @ 640x480, and fbset doesn't seem to work
> 
> 
> kernel boot parameter: video=matroxfb:vesa:0x11A
> This is supposed to be 1280x1024 16-bit, I'm not sure
> it works.  But X definitely sets the resolution to what it
> wants, on both screens. Exiting the accelerated server
> messes up the other screen as X "restores" the video card
> to previous settings.  

thanks

svetljo

-- 
Neu bei GMX: Preissenkung für MMS-Versand und FreeMMS!

Ideal für alle, die gerne MMS verschicken:
25 FreeMMS/Monat mit GMX TopMail.
http://www.gmx.net/de/cgi/produktemail

+++ GMX - die erste Adresse für Mail, Message, More! +++

Re: G550 bug ? (was Re: Independ multiple users on G550)

[Svetoslav S. <sv...@gm...>]

> On  1 Dec 03 at 20:27, Svetoslav Slavtchev wrote:
> > 
> > <hopeless wish>
> > is there a way to add an option for independand fb's
> > without matroxset
> > </hopeless wish>
> 
> No.
> 
> > could the problem be in the different resolutions of fb0 & fb1 ?
> > everything is OK if i use the default 640x480, the problem shows when
> > i try "options matroxfb_base vesa=0x117"
> > fb0 124x768 <-> fb1 640x480
> 
> matroxfb_swapped does not touch videomode, so it is really surprising
> that it clears yres for you. It only says which CRTC is connected
> to which OUTPUT.
> 
> Can you do:
> 
> fbset -fb /dev/fb0

<output 1>
mode "1024x768-60"
    # D: 64.994 MHz, H: 48.359 kHz, V: 59.998 Hz
    geometry 1024 768 1024 768 32
    timings 15386 160 32 30 4 128 4
    accel true
    rgba 8/16,8/8,8/0,8/24
endmode

> matroxset -f /dev/fb1 -m 0
> fbset -fb /dev/fb0

<output 2>
mode "1024x0-1273"
    # D: 64.994 MHz, H: 48.359 kHz, V: 1272.598 Hz
    geometry 1024 0 1024 0 32
    timings 15386 160 32 30 4 128 4
    accel true
    rgba 8/16,8/8,8/0,8/24
endmode

> matroxset -f /dev/fb0 -m 2
> fbset -fb /dev/fb0
<output 2>
> matroxset -f /dev/fb0 -m 0
> fbset -fb /dev/fb0
<output 2>
> matroxset -f /dev/fb0 -m 1
> fbset -fb /dev/fb0
<output 2>

> and post output here? I do not see any reason why matroxset should clear
> yres/yres_virtual unless you already did not have yres_virtual at zero
> before (then it will clip yres to yres_virtual, making it zero too).

svetljo

-- 
HoHoHo! Seid Ihr auch alle schön brav gewesen?

GMX Weihnachts-Special: Die 1. Adresse für Weihnachts-
männer und -frauen! http://www.gmx.net/de/cgi/specialmail

+++ GMX - die erste Adresse für Mail, Message, More! +++

Re: G550 bug ? (was Re: Independ multiple users on G550)

[Petr V. <VAN...@vc...>]

On  1 Dec 03 at 20:27, Svetoslav Slavtchev wrote:
> 
> <hopeless wish>
> is there a way to add an option for independand fb's
> without matroxset
> </hopeless wish>

No.

> could the problem be in the different resolutions of fb0 & fb1 ?
> everything is OK if i use the default 640x480, the problem shows when
> i try "options matroxfb_base vesa=0x117"
> fb0 124x768 <-> fb1 640x480

matroxfb_swapped does not touch videomode, so it is really surprising
that it clears yres for you. It only says which CRTC is connected
to which OUTPUT.

Can you do:

fbset -fb /dev/fb0
matroxset -f /dev/fb1 -m 0
fbset -fb /dev/fb0
matroxset -f /dev/fb0 -m 2
fbset -fb /dev/fb0
matroxset -f /dev/fb0 -m 0
fbset -fb /dev/fb0
matroxset -f /dev/fb0 -m 1
fbset -fb /dev/fb0

and post output here? I do not see any reason why matroxset should clear
yres/yres_virtual unless you already did not have yres_virtual at zero
before (then it will clip yres to yres_virtual, making it zero too).
                                                        Petr
                                                        

Re: Independ multiple users on G550

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

On Mon, Dec 01, 2003 at 02:41:32PM +0100, Svetoslav Slavtchev wrote:
> > 
> > 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.
> 
> hm, timing issues ?
> fbcon trying to setup consoles before
> matroxfb initialization is finished ?
> 
Or maybe X changes something?  It changes the resolution at least.

> may be we should experimenent to find the needed timeout,
> but this is probably dependant on the system
> 
I believe that is a wrong approach.  It should work as fast
as possible on any system, without race conditions or arbitrary waiting.

> or may be /* if it isn't already so */
> fbcon should wait for a signal from the framebuffers
> that they have finished initialization
> 

> well you can have a VGA console built in and load the fb stuff
> manually or with script later
> just built fb drivers & fbcon modular and don't load them too early
> 
> /* no fancy graphics at boot, but a workable VGA console */

That is indeed an option.  Perhaps I'll try that.

> > > 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.
> 
> NOPE
> same with XF driver fbdev for both heads
>  
When my pc boots it activates one screen only. The other one
is black.  That's what the bios do.  The other screen starts showing the
same as the first one when linux initialize the g550 framebuffers.

So it looks like the fb driver do this initially. when it ought to
set up one screen per framebuffer.  Later X mess with the
framebuffer/screen mappings everytime it sets screen resolution.
It probably sets resolution when switching to/from console too.
I don't know if X itself sets the resolution, or if it calls
into the fb driver to do it.  X is set up to use the fbdev,
who knows _what_ it uses it for.

> > > 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.
> 
> well may be,
> it would be nice to have a CONFIG_MATROXFB_SEPARATE_DISPLAYS,
> but i'm not sure it's doable, and i'm sure Petr is not working on it :(
> i think that the graphic BIOS initialize them in that way and the fbdriver 
> will have to work around these BIOS settings
> 
> > > 
> > > 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. :-( 
> 
> i actually do have it :-)
> 
> it disapeared with the option to disable PS2 input && serio
> you need "Generic Setup -> Remove kernel features (for embedded systems)" 
> enabled to be able to change them
>  
> i might try disabling it 
> / * not sure when i'll find time for that :( */
> 
> svetljo
> 
> PS
> 
> how do you setup the fb mode?
> i'm still using a single monitor with switch
> @ 640x480, and fbset doesn't seem to work


kernel boot parameter: video=matroxfb:vesa:0x11A
This is supposed to be 1280x1024 16-bit, I'm not sure
it works.  But X definitely sets the resolution to what it
wants, on both screens. Exiting the accelerated server
messes up the other screen as X "restores" the video card
to previous settings.  

Helge Hafting

Re: G550 bug ? (was Re: Independ multiple users on G550)

[Svetoslav S. <sv...@gm...>]

> On  1 Dec 03 at 20:03, Svetoslav Slavtchev wrote:
> 
> > [root@tux root]# fbset -fb /dev/fb0
> > 
> > mode "1024x768-60"
> >     # D: 64.994 MHz, H: 48.359 kHz, V: 59.998 Hz
> >     geometry 1024 768 1024 768 32
> >     timings 15386 160 32 30 4 128 4
> >     accel true
> >     rgba 8/16,8/8,8/0,8/24
> > endmode
> > [root@tux root]# matroxfb_swapped
> > [root@tux root]# fbset -fb /dev/fb0
> > 
> > mode "1024x0-1273"
> >     # D: 64.994 MHz, H: 48.359 kHz, V: 1272.598 Hz
> >     geometry 1024 0 1024 0 32
> >     timings 15386 160 32 30 4 128 4
> >     accel true
> >     rgba 8/16,8/8,8/0,8/24
> > endmode
> 
> What does 'matroxfb_swapped' do ? You have not only yres_virtual, but also
> yres set to 0. It looks to me like that 'matroxfb_swapped' asked for
> this...

it's swapped from matroxset tarball (see end of mail )
i have to run it in order to have independand heads,
until i run it fb0 is displayed on both fb0 & fb1

<hopeless wish>
is there a way to add an option for independand fb's
without matroxset
</hopeless wish>

> Driver in kernel is identical to driver on my site, except that features
> which are impossible to have with 2.6 fbdev kernel API were removed.
> But for mere users who do not need fbset, different resolutions on each
> display, textual displays or legacy svga games should not notice any 
> difference.
>                                                                 Petr
                                                              
could the problem be in the different resolutions of fb0 & fb1 ?
everything is OK if i use the default 640x480, the problem shows when
i try "options matroxfb_base vesa=0x117"
fb0 124x768 <-> fb1 640x480


svetljo

[root@tux root]# cat `which matroxfb_swapped `
#! /bin/sh

if [ -c /dev/fb0 ]; then
  HEAD0=/dev/fb0
  HEAD1=/dev/fb1
else
  HEAD0=/dev/fb/0
  HEAD1=/dev/fb/1
fi
matroxset -f ${HEAD1} -m 0
matroxset -f ${HEAD0} -m 2
matroxset -f ${HEAD1} -m 1

-- 
HoHoHo! Seid Ihr auch alle schön brav gewesen?

GMX Weihnachts-Special: Die 1. Adresse für Weihnachts-
männer und -frauen! http://www.gmx.net/de/cgi/specialmail

+++ GMX - die erste Adresse für Mail, Message, More! +++

Re: G550 bug ? (was Re: Independ multiple users on G550)

[Petr V. <VAN...@vc...>]

On  1 Dec 03 at 20:03, Svetoslav Slavtchev wrote:

> [root@tux root]# fbset -fb /dev/fb0
> 
> mode "1024x768-60"
>     # D: 64.994 MHz, H: 48.359 kHz, V: 59.998 Hz
>     geometry 1024 768 1024 768 32
>     timings 15386 160 32 30 4 128 4
>     accel true
>     rgba 8/16,8/8,8/0,8/24
> endmode
> [root@tux root]# matroxfb_swapped
> [root@tux root]# fbset -fb /dev/fb0
> 
> mode "1024x0-1273"
>     # D: 64.994 MHz, H: 48.359 kHz, V: 1272.598 Hz
>     geometry 1024 0 1024 0 32
>     timings 15386 160 32 30 4 128 4
>     accel true
>     rgba 8/16,8/8,8/0,8/24
> endmode

What does 'matroxfb_swapped' do ? You have not only yres_virtual, but also
yres set to 0. It looks to me like that 'matroxfb_swapped' asked for this...

Driver in kernel is identical to driver on my site, except that features
which are impossible to have with 2.6 fbdev kernel API were removed.
But for mere users who do not need fbset, different resolutions on each
display, textual displays or legacy svga games should not notice any 
difference.
                                                                Petr
                                                                

Re: G550 bug ? (was Re: Independ multiple users on G550)

[Svetoslav S. <sv...@gm...>]

> On  1 Dec 03 at 17:57, Svetoslav Slavtchev wrote:
> > > it is impossible for yres_virtual to ever become 65536... Besides that
> > > for 1024x65536/16bpp you need 128MB of videoram, and G550 can have
> only
> > > 32MB. So you screwed something a lot. You should get
> > > 
> > > matroxfb: Matrox G550 detected
> > > matroxfb: MTRR's turned on
> > > matroxfb: 1024x768x16bpp (virtual: 1024x8190)
> > > matroxfb: framebuffer at 0xDA000000, mapped to 0xe0810000, size
> 33554432
> > > Console: switching to colour frame buffer device 128x48
> > > fb0: MATROX frame buffer device
> > 
> > two questions 
> > 1.)
> >  is there a way to specify yres_virtual,
> >  i can not see such module option
> 
> You cannot specify it - you can only say 'yes, I want virtual scrolling'
> or 'no, I do not want it'. If you use 'video=matroxfb:nopan', driver will
> use yres_virtual == yres. If you do not specify it, driver attempts
> to use largest possible value smaller than 65536. Apparently for some
> reason fb_set_var() with yres_virtual == 65536 succeeds without
> changing passed var, although it should report back truncated
> yres_virtual....
> oh, stop! There is no fb_set_var call in stock matroxfb. Can you try
> opening
> drivers/video/matrox/matroxfb_base.c in your favorite text editor and
> locakte
> 
>   matroxfb_init_fix(PMINFO2);
>   err = -EINVAL;
> 
> and add
> 
>   fb_set_var(&ACCESS_FBINFO(fbcon), &vesafb_defined);
>   
> between these two lines there... It should then use proper (~8190) vyres 
> instead of 64K. But probably vgacon -> matroxfb will stop working after 
> that, and you'll see whole screen as bright white instead of text 
> inherited from vgacon.

everything lloks OK in dmesg, but running swapped still breaks
both without/with nopan=1

-----withount nopan
matroxfb: Matrox G550 detected
matroxfb: MTRR's turned on
matroxfb: 1024x768x32bpp (virtual: 1024x4096)
matroxfb: framebuffer at 0xD8000000, mapped to 0xe0ca9000, size 16777216
fb0: MATROX frame buffer device
fb0: initializing hardware
matroxfb_crtc2: secondary head of fb0 was registered as fb1
-----with nopan=1
matroxfb: Matrox G550 detected
matroxfb: MTRR's turned on
matroxfb: 1024x768x32bpp (virtual: 1024x768)
matroxfb: framebuffer at 0xD8000000, mapped to 0xe0ca9000, size 16777216
fb0: MATROX frame buffer device
fb0: initializing hardware
matroxfb_crtc2: secondary head of fb0 was registered as fb1
[root@tux root]# fbset -fb /dev/fb0

mode "1024x768-60"
    # D: 64.994 MHz, H: 48.359 kHz, V: 59.998 Hz
    geometry 1024 768 1024 768 32
    timings 15386 160 32 30 4 128 4
    accel true
    rgba 8/16,8/8,8/0,8/24
endmode
[root@tux root]# matroxfb_swapped
[root@tux root]# fbset -fb /dev/fb0

mode "1024x0-1273"
    # D: 64.994 MHz, H: 48.359 kHz, V: 1272.598 Hz
    geometry 1024 0 1024 0 32
    timings 15386 160 32 30 4 128 4
    accel true
    rgba 8/16,8/8,8/0,8/24
endmode

> > 2.) 
> >  how should one adjust the mode for head2,
> >  matroxfb_crtc2 has only a "mem" option
> 
> fbset. crtc2 always begins in 640x480/32bpp, as it cannot be your 
> boot monitor, so you can always run fbset. Unless you have 2.6.x
> fbset-less
> kernel, in which case you have just bad luck...

fbdev bk tree should support fbset, but let see when it will be merged in
2.6
/* or in ruby */

> > > I'd say that if you want support from me, you should use my code...
> > > I have no idea what you are doing in your tree, but you are apparently
> > > doing wrong things...
> > 
> > just asking :(
> > i'm not a kernel programmer, and i'm not familiar with the fb /console
> > internals
> > if i was i would try to merge your driver, but i'm not so ...
> > 
> > and as said your driver makes deep changes to the FB API, which IMHO are
> > incompatible
> > with ruby
> 
> Version in kernel just uses standard fbdev API present in 2.6.x kernel.

i ment the driver you actively work on, the one on your ftp/http page


best,

svetljo

-- 
Neu bei GMX: Preissenkung für MMS-Versand und FreeMMS!

Ideal für alle, die gerne MMS verschicken:
25 FreeMMS/Monat mit GMX TopMail.
http://www.gmx.net/de/cgi/produktemail

+++ GMX - die erste Adresse für Mail, Message, More! +++

Re: G550 bug ? (was Re: Independ multiple users on G550)

[Petr V. <VAN...@vc...>]

On  1 Dec 03 at 17:57, Svetoslav Slavtchev wrote:
> > it is impossible for yres_virtual to ever become 65536... Besides that
> > for 1024x65536/16bpp you need 128MB of videoram, and G550 can have only
> > 32MB. So you screwed something a lot. You should get
> > 
> > matroxfb: Matrox G550 detected
> > matroxfb: MTRR's turned on
> > matroxfb: 1024x768x16bpp (virtual: 1024x8190)
> > matroxfb: framebuffer at 0xDA000000, mapped to 0xe0810000, size 33554432
> > Console: switching to colour frame buffer device 128x48
> > fb0: MATROX frame buffer device
> 
> two questions 
> 1.)
>  is there a way to specify yres_virtual,
>  i can not see such module option

You cannot specify it - you can only say 'yes, I want virtual scrolling'
or 'no, I do not want it'. If you use 'video=matroxfb:nopan', driver will
use yres_virtual == yres. If you do not specify it, driver attempts
to use largest possible value smaller than 65536. Apparently for some
reason fb_set_var() with yres_virtual == 65536 succeeds without
changing passed var, although it should report back truncated yres_virtual....
oh, stop! There is no fb_set_var call in stock matroxfb. Can you try opening
drivers/video/matrox/matroxfb_base.c in your favorite text editor and
locakte

  matroxfb_init_fix(PMINFO2);
  err = -EINVAL;

and add

  fb_set_var(&ACCESS_FBINFO(fbcon), &vesafb_defined);
  
between these two lines there... It should then use proper (~8190) vyres 
instead of 64K. But probably vgacon -> matroxfb will stop working after 
that, and you'll see whole screen as bright white instead of text 
inherited from vgacon.

> 2.) 
>  how should one adjust the mode for head2,
>  matroxfb_crtc2 has only a "mem" option

fbset. crtc2 always begins in 640x480/32bpp, as it cannot be your 
boot monitor, so you can always run fbset. Unless you have 2.6.x fbset-less
kernel, in which case you have just bad luck...

> > I'd say that if you want support from me, you should use my code...
> > I have no idea what you are doing in your tree, but you are apparently
> > doing wrong things...
> 
> just asking :(
> i'm not a kernel programmer, and i'm not familiar with the fb /console
> internals
> if i was i would try to merge your driver, but i'm not so ...
> 
> and as said your driver makes deep changes to the FB API, which IMHO are
> incompatible
> with ruby

Version in kernel just uses standard fbdev API present in 2.6.x kernel.

> i know i can not ask for support at least until 2.7 is open and ruby merged
> into it,
> and even then may be you'll keep your driver out of tree which will
> complicate support questions

Yes, I support only standard Linus (or soon Andrew's) kernel.
                                                                Petr
                                                                

Re: G550 bug ? (was Re: Independ multiple users on G550)

[Svetoslav S. <sv...@gm...>]

> On  1 Dec 03 at 17:02, Svetoslav Slavtchev wrote:
> > 
> > is this a matroxfb bug ?
> 
> Maybe. But I'd say that you broke fbdev API matroxfb expects.

theoretically it should be mostly the same as in Linus tree

> > > matroxfb: MTRR's turned on
> > > matroxfb: 1024x768x16bpp (virtual: 1024x65536)
> > > fbcon_startup: res:    1024x0-16
> 
> Like that you are somewhere truncating values to 16 bits?! Thus 65536 == 0
> in your arithmetic... And as matroxfb's code does
> 
> if (var->yres_virtual > 32767)
>    var->yres_virtual = 32767;
> 
> it is impossible for yres_virtual to ever become 65536... Besides that
> for 1024x65536/16bpp you need 128MB of videoram, and G550 can have only
> 32MB. So you screwed something a lot. You should get
> 
> matroxfb: Matrox G550 detected
> matroxfb: MTRR's turned on
> matroxfb: 1024x768x16bpp (virtual: 1024x8190)
> matroxfb: framebuffer at 0xDA000000, mapped to 0xe0810000, size 33554432
> Console: switching to colour frame buffer device 128x48
> fb0: MATROX frame buffer device

two questions 
1.)
 is there a way to specify yres_virtual,
 i can not see such module option

2.) 
 how should one adjust the mode for head2,
 matroxfb_crtc2 has only a "mem" option

> 
> I'd say that if you want support from me, you should use my code...
> I have no idea what you are doing in your tree, but you are apparently
> doing wrong things...

just asking :(
i'm not a kernel programmer, and i'm not familiar with the fb /console
internals
if i was i would try to merge your driver, but i'm not so ...

and as said your driver makes deep changes to the FB API, which IMHO are
incompatible
with ruby

i know i can not ask for support at least until 2.7 is open and ruby merged
into it,
and even then may be you'll keep your driver out of tree which will
complicate support questions

may be just asking for pointers whats going wrong, so Aivils or James can
fix it

best,

svetljo

-- 
Neu bei GMX: Preissenkung für MMS-Versand und FreeMMS!

Ideal für alle, die gerne MMS verschicken:
25 FreeMMS/Monat mit GMX TopMail.
http://www.gmx.net/de/cgi/produktemail

+++ GMX - die erste Adresse für Mail, Message, More! +++

Re: G550 bug ? (was Re: Independ multiple users on G550)

[Petr V. <VAN...@vc...>]

On  1 Dec 03 at 17:02, Svetoslav Slavtchev wrote:
> 
> is this a matroxfb bug ?

Maybe. But I'd say that you broke fbdev API matroxfb expects.

> > matroxfb: MTRR's turned on
> > matroxfb: 1024x768x16bpp (virtual: 1024x65536)
> > fbcon_startup: res:    1024x0-16

Like that you are somewhere truncating values to 16 bits?! Thus 65536 == 0
in your arithmetic... And as matroxfb's code does

if (var->yres_virtual > 32767)
   var->yres_virtual = 32767;

it is impossible for yres_virtual to ever become 65536... Besides that
for 1024x65536/16bpp you need 128MB of videoram, and G550 can have only
32MB. So you screwed something a lot. You should get

matroxfb: Matrox G550 detected
matroxfb: MTRR's turned on
matroxfb: 1024x768x16bpp (virtual: 1024x8190)
matroxfb: framebuffer at 0xDA000000, mapped to 0xe0810000, size 33554432
Console: switching to colour frame buffer device 128x48
fb0: MATROX frame buffer device

I'd say that if you want support from me, you should use my code...
I have no idea what you are doing in your tree, but you are apparently
doing wrong things...
                                                Petr Vandrovec
                                                

G550 bug ? (was Re: Independ multiple users on G550)

[Svetoslav S. <sv...@gm...>]

Hi Petr,
Hi all,

is this a matroxfb bug ?

> > >how do you setup the fb mode?
> > >i'm still using a single monitor with switch
> > >@ 640x480, and fbset doesn't seem to work
> > 
> > video=matroxfb:800x600@75
> > 
> > for 1st head. Also i use fbset. Modular fbcon donot resize after
> > fbset resize.
> > 
> 
> nice but
> ------- modprobe.conf -------------
> options matroxfb_base mem=16 vesa=0x117
> options matroxfb_crtc2 mem=16
> ---------------------------------------
> 
> matroxfb: Matrox G550 detected
> matroxfb: MTRR's turned on
> matroxfb: 1024x768x16bpp (virtual: 1024x65536)
> matroxfb: framebuffer at 0xD8000000, mapped to 0xe0ca9000, size 16777216
> fb0: MATROX frame buffer device
> fb0: initializing hardware
> matroxfb_crtc2: secondary head of fb0 was registered as fb1
> fbcon_startup: mode:   MATROX
> fbcon_startup: visual: 2
> fbcon_startup: res:    1024x0-16
> Console: switching to colour MATROX 128x25 vc:1-16
> fbcon_startup: mode:   MATROX DH
> fbcon_startup: visual: 2
> fbcon_startup: res:    640x480-32
> Console: Colour MATROX DH 80x30 vc:17-32
> 
> do you see  the nice "fbcon_startup: res:    1024x0-16"
> both heads are off after that
> /* everything quite normal before loading fbcon */
> 
> and 
> ---------------------------------------
> [root@tux root]# fbset -fb /dev/fb0 1024x768-70
> [root@tux root]# fbset -fb /dev/fb0
> 
> mode "1024x0-1486"
>     # D: 74.996 MHz, H: 56.473 kHz, V: 1486.134 Hz
>     geometry 1024 0 1024 0 8
>     timings 13334 144 24 29 3 136 6
>     accel true
>     rgba 8/0,8/0,8/0,0/0
> endmode
> 
> [root@tux root]# fbset -fb /dev/fb0 800x600-70
> [root@tux root]# fbset -fb /dev/fb0
> 
> mode "800x0-1237"
>     # D: 44.899 MHz, H: 44.543 kHz, V: 1237.308 Hz
>     geometry 800 0 832 0 8
>     timings 22272 40 24 15 9 144 12
>     hsync high
>     accel true
>     rgba 8/0,8/0,8/0,0/0
> endmode
> -------------------------------------------------
> 
> any clues, ideas ?
> 
> 
> svetljo
> 
> PS.
> the latest cvs works OK modular,
> at least in default mode 640x480

PS.2

the same happens without loading fbcon when swapped or normal from 
the matroxset tarball are executed

this is without fbcon loaded 
/* over ssh, quite easy to reproduce with modular matroxfb */
same with vesa=0x118

[root@tux root]# fbset -fb /dev/fb0

mode "1024x768-60"
    # D: 64.994 MHz, H: 48.359 kHz, V: 59.998 Hz
    geometry 1024 768 1024 4096 32
    timings 15386 160 32 30 4 128 4
    accel true
    rgba 8/16,8/8,8/0,8/24
endmode

[root@tux root]# fbset -fb /dev/fb1

mode "640x480-60"
    # D: 25.176 MHz, H: 31.469 kHz, V: 59.942 Hz
    geometry 640 480 640 480 32
    timings 39721 48 16 33 10 96 2
    rgba 8/16,8/8,8/0,8/24
endmode

[root@tux root]# matroxfb_swapped
[root@tux root]# fbset -fb /dev/fb0

mode "1024x0-1273"
    # D: 64.994 MHz, H: 48.359 kHz, V: 1272.598 Hz
    geometry 1024 0 1024 0 32
    timings 15386 160 32 30 4 128 4
    accel true
    rgba 8/16,8/8,8/0,8/24
endmode

[root@tux root]# fbset -fb /dev/fb1

mode "640x480-60"
    # D: 25.176 MHz, H: 31.469 kHz, V: 59.942 Hz
    geometry 640 480 640 480 32
    timings 39721 48 16 33 10 96 2
    rgba 8/16,8/8,8/0,8/24
endmode

[root@tux root]# fbset -fb /dev/fb0 640x480-60
[root@tux root]# fbset -fb /dev/fb0

mode "640x0-699"
    # D: 25.175 MHz, H: 31.469 kHz, V: 699.305 Hz
    geometry 640 0 640 0 8
    timings 39722 48 16 33 10 96 2
    accel true
    rgba 8/0,8/0,8/0,0/0
endmode

best,

svetljo

-- 
Neu bei GMX: Preissenkung für MMS-Versand und FreeMMS!

Ideal für alle, die gerne MMS verschicken:
25 FreeMMS/Monat mit GMX TopMail.
http://www.gmx.net/de/cgi/produktemail

+++ GMX - die erste Adresse für Mail, Message, More! +++

Re: Independ multiple users on G550

[Svetoslav S. <sv...@gm...>]

> 
> >> > 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?
> >
> >good question
> 
> When "foo" device detected, then kernel call /etc/hotplug/input.agent
> Troubles are non-existing file systems in bootime, /proc and so on.
> So all Your devices detected in boot time and input.agent has read-only
> root filesytem and nothing more. This is main reason to use input device
> drivers modular. Instead modules exists input.rc scripts, which do same.
> 
> >how do you setup the fb mode?
> >i'm still using a single monitor with switch
> >@ 640x480, and fbset doesn't seem to work
> 
> video=matroxfb:800x600@75
> 
> for 1st head. Also i use fbset. Modular fbcon donot resize after
> fbset resize.
> 

nice but
------- modpreobe.conf -------------
options matroxfb_base mem=16 vesa=0x117
options matroxfb_crtc2 mem=16
---------------------------------------

matroxfb: Matrox G550 detected
matroxfb: MTRR's turned on
matroxfb: 1024x768x16bpp (virtual: 1024x65536)
matroxfb: framebuffer at 0xD8000000, mapped to 0xe0ca9000, size 16777216
fb0: MATROX frame buffer device
fb0: initializing hardware
matroxfb_crtc2: secondary head of fb0 was registered as fb1
fbcon_startup: mode:   MATROX
fbcon_startup: visual: 2
fbcon_startup: res:    1024x0-16
Console: switching to colour MATROX 128x25 vc:1-16
fbcon_startup: mode:   MATROX DH
fbcon_startup: visual: 2
fbcon_startup: res:    640x480-32
Console: Colour MATROX DH 80x30 vc:17-32

do you see  the nice "fbcon_startup: res:    1024x0-16"
both heads are off after that
/* everything quite normal before loading fbcon */

and 
---------------------------------------
[root@tux root]# fbset -fb /dev/fb0 1024x768-70
[root@tux root]# fbset -fb /dev/fb0

mode "1024x0-1486"
    # D: 74.996 MHz, H: 56.473 kHz, V: 1486.134 Hz
    geometry 1024 0 1024 0 8
    timings 13334 144 24 29 3 136 6
    accel true
    rgba 8/0,8/0,8/0,0/0
endmode

[root@tux root]# fbset -fb /dev/fb0 800x600-70
[root@tux root]# fbset -fb /dev/fb0

mode "800x0-1237"
    # D: 44.899 MHz, H: 44.543 kHz, V: 1237.308 Hz
    geometry 800 0 832 0 8
    timings 22272 40 24 15 9 144 12
    hsync high
    accel true
    rgba 8/0,8/0,8/0,0/0
endmode
-------------------------------------------------

any clues, ideas ?


svetljo

PS.
the latest cvs works OK modular,
at least in default mode 640x480

-- 
HoHoHo! Seid Ihr auch alle schön brav gewesen?

GMX Weihnachts-Special: Die 1. Adresse für Weihnachts-
männer und -frauen! http://www.gmx.net/de/cgi/specialmail

+++ GMX - die erste Adresse für Mail, Message, More! +++