Menu
▾
▴
linux-fbdev-devel — linux-fbdev mailing list for project developers
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
(1) |
Apr
(104) |
May
(81) |
Jun
(248) |
Jul
(133) |
Aug
(33) |
Sep
(53) |
Oct
(82) |
Nov
(166) |
Dec
(71) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(121) |
Feb
(42) |
Mar
(39) |
Apr
(84) |
May
(87) |
Jun
(58) |
Jul
(97) |
Aug
(130) |
Sep
(32) |
Oct
(139) |
Nov
(108) |
Dec
(216) |
| 2003 |
Jan
(299) |
Feb
(136) |
Mar
(392) |
Apr
(141) |
May
(137) |
Jun
(107) |
Jul
(94) |
Aug
(262) |
Sep
(300) |
Oct
(216) |
Nov
(72) |
Dec
(94) |
| 2004 |
Jan
(174) |
Feb
(192) |
Mar
(215) |
Apr
(314) |
May
(319) |
Jun
(293) |
Jul
(205) |
Aug
(161) |
Sep
(192) |
Oct
(226) |
Nov
(308) |
Dec
(89) |
| 2005 |
Jan
(127) |
Feb
(269) |
Mar
(588) |
Apr
(106) |
May
(77) |
Jun
(77) |
Jul
(161) |
Aug
(239) |
Sep
(86) |
Oct
(112) |
Nov
(153) |
Dec
(145) |
| 2006 |
Jan
(87) |
Feb
(57) |
Mar
(129) |
Apr
(109) |
May
(102) |
Jun
(232) |
Jul
(97) |
Aug
(69) |
Sep
(67) |
Oct
(69) |
Nov
(214) |
Dec
(82) |
| 2007 |
Jan
(133) |
Feb
(307) |
Mar
(121) |
Apr
(171) |
May
(229) |
Jun
(156) |
Jul
(185) |
Aug
(160) |
Sep
(122) |
Oct
(130) |
Nov
(78) |
Dec
(27) |
| 2008 |
Jan
(105) |
Feb
(137) |
Mar
(146) |
Apr
(148) |
May
(239) |
Jun
(208) |
Jul
(157) |
Aug
(244) |
Sep
(119) |
Oct
(125) |
Nov
(189) |
Dec
(225) |
| 2009 |
Jan
(157) |
Feb
(139) |
Mar
(106) |
Apr
(130) |
May
(246) |
Jun
(189) |
Jul
(128) |
Aug
(127) |
Sep
(88) |
Oct
(86) |
Nov
(216) |
Dec
(9) |
| 2010 |
Jan
(5) |
Feb
|
Mar
(11) |
Apr
(31) |
May
(3) |
Jun
|
Jul
(7) |
Aug
|
Sep
(1) |
Oct
|
Nov
(1) |
Dec
|
| 2012 |
Jan
|
Feb
|
Mar
(3) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Romain D. <do...@ir...> - 2002-01-16 17:01:35
|
Sven wrote: > Ok, i was just asking anyway. On second thought, it wouldn't be necessary to sort : during the auto-allocating, I only need to add not the first board, but the board with the same Bus/Device and lowest function number. Could be done in the same loop, only in the end instead of the middle. OTOH, it 'pciid' works...... ;-) ;-) ;-) -- DOLBEAU Romain | Brothers of Metal will always be there ENS Cachan / Ker Lann | Standing together with hands in the air Thesard IRISA / CAPS | -- Manowar, dol...@cl... | 'Brothers of Metal' |
|
From: Sven <lu...@dp...> - 2002-01-16 16:58:00
|
On Wed, Jan 16, 2002 at 05:53:28PM +0100, Romain Dolbeau wrote: > Sven wrote: > > > Since you are able to get the correct order (as the message proves) it could > > be possible to re-order it accordyingly ? > > The head number is simply the same as the PCI function > number ;-) Ok, i was just asking anyway. Friendly, Sven Luther |
|
From: Romain D. <do...@ir...> - 2002-01-16 16:53:40
|
Sven wrote: > Since you are able to get the correct order (as the message proves) it could > be possible to re-order it accordyingly ? The head number is simply the same as the PCI function number ;-) I could try to add code to sort the chip according to the function number, but that code would only be useful for multi-head boards on some weirds mobo/kernel combinations... Would that really be useful ? And that would only sort heads on a board, not boards, as you can't guess which PCI bus/device should be the first head... Thinking of it, one could even build a board with the first head on the highest-number function... Honestly, if the 'pciid' trick works for you, I don't think I'll add the sorting. It would be better to 'fix' pci_find_device to get reliable/consistent behavior IMHO. -- DOLBEAU Romain | Who made you God to say ENS Cachan / Ker Lann | "I'll take your life from you!" Thesard IRISA / CAPS | -- Metallica, dol...@cl... | 'Ride the Lightning' |
|
From: Sven <lu...@dp...> - 2002-01-16 16:42:07
|
On Wed, Jan 16, 2002 at 05:28:40PM +0100, Romain Dolbeau wrote: > Sven wrote: > > > Ok, i suppose pci_find_device does things wrong fro the ECS K7s5a motherboard, > > is this something i should take elsewhere ? > > Well, I don't think the behavior is clearly defined, so > it's probably not a bug to return the PCI device > in (seemingly) random order. pm3fb has the 'pciid' > trick, so a workaround exist... But, ... Since you are able to get the correct order (as the message proves) it could be possible to re-order it accordyingly ? Or does it causes big problems to do such ? Friendly, Sven Luther |
|
From: Romain D. <do...@ir...> - 2002-01-16 16:36:18
|
Sven wrote: > Ok, i suppose pci_find_device does things wrong fro the ECS K7s5a motherboard, > is this something i should take elsewhere ? Well, I don't think the behavior is clearly defined, so it's probably not a bug to return the PCI device in (seemingly) random order. pm3fb has the 'pciid' trick, so a workaround exist... -- DOLBEAU Romain | You won't break me ENS Cachan / Ker Lann | You won't make me Thesard IRISA / CAPS | You won't take me dol...@cl... | -- Judas Priest, 'Blood Red Skies' |
|
From: Sven <lu...@dp...> - 2002-01-16 16:29:30
|
On Wed, Jan 16, 2002 at 05:10:04PM +0100, Romain Dolbeau wrote: > Sven wrote: > > > I don't really understand what happens here, but adding an off:0: did make the > > console appear on the first head again. (BTW, what hinted me to this is the > > fact that pm3fb was reporting Appian J2000 head 2, so pm3fb can recognize the > > correct head number, just doesn't use it to attribute it to the fbs.) > > No, fb are registered in the order they are found, i.e. the order > of the "pci_find_device()" function. I have no idea how this > one behave with regards to motherboard. Ok, i suppose pci_find_device does things wrong fro the ECS K7s5a motherboard, is this something i should take elsewhere ? But then, both X and pm3fb identify the right chip as the first one. > You should be able to use the "pciid" option to put things back > in order. i.e. "pciid:0:1:0:1,pciid:1:1:0:2" (assuming pci bus > & device number are 1 & 0) *should* restore the old behavior. > > The name is not used at all, it's only to make the user > feel better, with the board name in dmesg ;-) Seriously, > it's only used to try to get proper timings for the memory. Ah, ok, ... > > BTW, is ruby supposed to work ? I compiled yesterday a 2.5.1 kernel + ruby, > > and after booting into it, it hangs immediately at the begining (4-5th line of > > the kernel log). 2.5.2 + vesafb but no ruby works fine though. > > No, it's not. I never managed to get Ruby working on my box, > so I can't even try pm3fb/ruby. When ruby start working OK > on PPC, I might try to make pm3fb works in it, if I find > the time. mmm, ... I hope you will get the time for it, ... I could do it, but don't have time also for it right now. Friendly, Sven Luther |
|
From: Romain D. <do...@ir...> - 2002-01-16 16:10:38
|
Sven wrote: > I don't really understand what happens here, but adding an off:0: did make the > console appear on the first head again. (BTW, what hinted me to this is the > fact that pm3fb was reporting Appian J2000 head 2, so pm3fb can recognize the > correct head number, just doesn't use it to attribute it to the fbs.) No, fb are registered in the order they are found, i.e. the order of the "pci_find_device()" function. I have no idea how this one behave with regards to motherboard. You should be able to use the "pciid" option to put things back in order. i.e. "pciid:0:1:0:1,pciid:1:1:0:2" (assuming pci bus & device number are 1 & 0) *should* restore the old behavior. The name is not used at all, it's only to make the user feel better, with the board name in dmesg ;-) Seriously, it's only used to try to get proper timings for the memory. > BTW, is ruby supposed to work ? I compiled yesterday a 2.5.1 kernel + ruby, > and after booting into it, it hangs immediately at the begining (4-5th line of > the kernel log). 2.5.2 + vesafb but no ruby works fine though. No, it's not. I never managed to get Ruby working on my box, so I can't even try pm3fb/ruby. When ruby start working OK on PPC, I might try to make pm3fb works in it, if I find the time. -- DOLBEAU Romain | The Gods made Heavy Metal ENS Cachan / Ker Lann | and it's never gonna die Thesard IRISA / CAPS | -- Manowar, dol...@cl... | 'The Gods made Heavy Metal' |
|
From: Sven <lu...@dp...> - 2002-01-16 15:39:21
|
On Tue, Jan 08, 2002 at 03:00:12PM +0100, Romain Dolbeau wrote: > Sven wrote: > > > Well, i did try fbset 640x480, but since i could not see any output, i don't > > believe it worked, but maybe i mistyped something. > > Try using boot-time option, if possible (the theory is > that is should'nt matter, but who knows ? :-) Mmm, a bit more looking at this and i found out that pm3fb worked, but was displaying on the second head, ... Apparently this new motherboard i have somehow inverts both heads or something such. I don't really understand what happens here, but adding an off:0: did make the console appear on the first head again. (BTW, what hinted me to this is the fact that pm3fb was reporting Appian J2000 head 2, so pm3fb can recognize the correct head number, just doesn't use it to attribute it to the fbs.) BTW, is ruby supposed to work ? I compiled yesterday a 2.5.1 kernel + ruby, and after booting into it, it hangs immediately at the begining (4-5th line of the kernel log). 2.5.2 + vesafb but no ruby works fine though. Friendly, Sven Luther |
|
From: James S. <jsi...@tr...> - 2002-01-16 01:07:11
|
Hi folks!!
On to the massive fbdev cleanup. The second patch requires the first
patch. The first patch is the currcon one that I posted earlier. Every
driver makes use of the currcon field in struct fb_info. The second patch
makes every driver start to use fbgen. The first function that is mass
reproduced in every driver do_install_cmap is removed to one spot. I like
people to test this before it is sent off to Dave Jones. The patches are
big so here is the link to them:
. ---
|o_o |
|:_/ | Give Micro$oft the Bird!!!!
// \ \ Use Linux!!!!
(| | )
/'_ _/`\
___)=(___/
http://www.transvirtual.com/~jsimmons/fbcurrcon.diff
http://www.transvirtual.com/~jsimmons/doinstallcmap.diff
Have fun. I have tested on my local machine. Works like a charm.
|
|
From: James S. <jsi...@tr...> - 2002-01-16 00:20:31
|
For some time now we have seen framebuffer device drivers appear and then disappear. Plus they are scattered every where and often several people are working on the same driver without knowing each other. What I like to see is drivers collected into one spot for people to grab. Such a spot exist but people are not aware of it. That is at the fbdev web site. So if you have a driver and would like to have it placed somewhere where people might actually look at it and this way we can avoid code duplication please let me or Geert know. We will gladly place it into CVS at the fbdev sourceforge site. http://linux-fbdev.sf.net Thank you. . --- |o_o | |:_/ | Give Micro$oft the Bird!!!! // \ \ Use Linux!!!! (| | ) /'_ _/`\ ___)=(___/ |
|
From: James S. <jsi...@tr...> - 2002-01-15 23:24:01
|
> just as an off topic question, is there a plan to get this into kernel > 2.5.x at any point? im trying to decide wether to develop a driver for > the old style (2.2.16), or for the new one (or both, i suppose). > seeing some of this code in action would greatly help, and would be a step > in the right direction for fbdev. Both is the plan. I plan to back port it to 2.4.X. P.S I didn't see anyone protest the currcon patch so I plan to send it off to David. Any objections? |
|
From: Chris W. <cw...@so...> - 2002-01-15 21:11:06
|
> This patch only applies for the -dj tree since the new fbdev api is going > in there for now. This patch makes every fbdev driver uses the currcon > that I have placed in struct fb_info. Currently most drivers have currcon, just as an off topic question, is there a plan to get this into kernel 2.5.x at any point? im trying to decide wether to develop a driver for the old style (2.2.16), or for the new one (or both, i suppose). seeing some of this code in action would greatly help, and would be a step in the right direction for fbdev. thanks! chris |
|
From: James S. <jsi...@tr...> - 2002-01-15 04:27:00
|
> On Mon, Jan 14, 2002 at 04:39:43PM -0800, James Simmons wrote: > > [stuff about currcon] > > I've killed currcon completely in the cyber2000fb driver in favour of > tracking which struct display is current. Tracking 'currcon', doing > a whole pile of special cases, and copying 'var' stuff to/from fb.var > didn't make sense anymore. I'm expecting the same thing will happen > with the other stuff in the struct fb_info. But struct display is going to go away!!!!!! You haven't seen the complete new fbdev api. How much cleaner and superior to the current stuff. http://linuxconsole.sf.net The whole point was to make the fbdev layer independent of the VT tty system. It makes no sense to have a tty on something like a iPAQ. This way you can a /dev/fb interface with no VT. You can also do other nice things like have a vga console on one display and still have a fbdev driver. Think about how much easier it would be to debug a fbdev driver that way. BTW that is how I was testing the new fbdev api. Having printk on a vga terminal will looking at printks while testing the fbdev driver. It was so nice. Plus the amount of code reduction will be huge. I mean huge. Over the years the lower level console drivers have been building crude to make up for the limitations of the upper console layer. This will be cleaned up for 2.5.X. So now fbcon will be a wrapper around the fbdev layer if we do want to use a VT. It will make a very nice small footprint for embedded systems. BTW this was my goal. Another bonus will be I will make the VT system modular. So if we do want a VT we can :-) I haven't had the time to do this but I plan to. I wanted to test it on a iPAQ with a stowaway keyboard. Think about the power of insmod a keyboard driver, fbcon.o and then insmod vt.o. Talk about having a even smaller kernel image to put in a partition. Some devices only have 512K of space to place a bootable kernel. As time goes on it is becoming harder and harder to do this. Now we can!!!!!! It just makes me excited thinking about it:-) > (Think about the current cyber2000fb code, and what happens to other > consoles when you fbset 800x600-60 -a and then switch to them to > discover you only have a 640x480 window where the characters appear). This will be fixed and very soon. Trust me. P.S currcon is a temporary step to deal with the issue of only one foreground console. It will also GO AWAY as the console system is truly fixed to support multiple desktops. Yes I have such a system at home so it is possible. The only reason I'm doing it this way is so when I start changing the console layer I don't have to rewrite ever single fbdev driver. Or do you think I should rework the console layer first. |
|
From: Russell K. <rm...@ar...> - 2002-01-15 00:57:12
|
On Mon, Jan 14, 2002 at 04:39:43PM -0800, James Simmons wrote:
> [stuff about currcon]
I've killed currcon completely in the cyber2000fb driver in favour of
tracking which struct display is current. Tracking 'currcon', doing
a whole pile of special cases, and copying 'var' stuff to/from fb.var
didn't make sense anymore. I'm expecting the same thing will happen
with the other stuff in the struct fb_info.
(Think about the current cyber2000fb code, and what happens to other
consoles when you fbset 800x600-60 -a and then switch to them to
discover you only have a 640x480 window where the characters appear).
--
Russell King (rm...@ar...) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
|
|
From: James S. <jsi...@tr...> - 2002-01-15 00:39:52
|
This patch only applies for the -dj tree since the new fbdev api is going in there for now. This patch makes every fbdev driver uses the currcon that I have placed in struct fb_info. Currently most drivers have currcon, not the one for the console system, global. This is a problem if you have more than one card. I have tested to see if this compiles on ix86 but this patch is extensive so I like people to apply this patch to test it out against the dj14 tree. The patch is to big to post so it is avalibale at the following link: NOTE: The setcolreg patch has to be applied first. http://www.transvirtual.com/~jsimmons/setcolreg.diff http://www.transvirtual.com/~jsimmons/fbcurrcon.diff . --- |o_o | |:_/ | Give Micro$oft the Bird!!!! // \ \ Use Linux!!!! (| | ) /'_ _/`\ ___)=(___/ |
|
From: Robert F. <rob...@pa...> - 2002-01-11 19:14:19
|
The module radeon_fb.c that is in linux-2.4.18-pre3 fails to compile due to missing definitions for TMDS_TRANSMITTER_CNTL and others. The error message is below. The problem developed somewhere between 2.4.17 and 2.4.18-pre2. One possible cause would be a patch entered for radeon_fb.c without the corresponding patch for radeon.h -bob rob...@pa... Compile error message (Redhat 7.2): gcc -D__KERNEL__ -I/usr/src/linux-2.4.18-pre3/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common -pipe -mpreferred-stack-boundary=2 -march=i686 -DMODULE -DMODVERSIONS -include /usr/src/linux-2.4.18-pre3/include/linux/modversions.h -DKBUILD_BASENAME=radeonfb -c -o radeonfb.o radeonfb.c radeonfb.c: In function `radeon_save_state': radeonfb.c:2283: `TMDS_TRANSMITTER_CNTL' undeclared (first use in this function)radeonfb.c:2283: (Each undeclared identifier is reported only once radeonfb.c:2283: for each function it appears in.) radeonfb.c: In function `radeon_load_video_mode': radeonfb.c:2560: `TMDS_RAN_PAT_RST' undeclared (first use in this function) radeonfb.c:2561: `ICHCSEL' undeclared (first use in this function) radeonfb.c:2561: `TMDS_PLLRST' undeclared (first use in this function) radeonfb.c: In function `radeon_write_mode': radeonfb.c:2650: `TMDS_TRANSMITTER_CNTL' undeclared (first use in this function)radeonfb.c:2655: `LVDS_STATE_MASK' undeclared (first use in this function) radeonfb.c: At top level: radeonfb.c:2957: warning: `fbcon_radeon8' defined but not used |
|
From: Petr V. <VAN...@vc...> - 2002-01-10 11:48:17
|
On 9 Jan 02 at 23:20, Carl Wilhelm Soderstrom wrote:
> once a long time ago, Petr Vandrovec was kind enough to write:
> test #1
> settings:
> PCI (ATI Xpert 98 - Mach64 chip) primary display (as set in the BIOS).
> no video= options
> result:
> nothing readable on any of the 3 heads.
> ATI - blank; tho there were some white pixels scrolling by on the left side
> of the screen at boot time.
> Matrox Head #1 - generally bluish pattern of 'snow' (in regular linear
> patterns).
> Matrox Head #2 - purplish pattern of 'wavy lines'
It is expected if your kernel does not know DAC used on ATI (or your
flavor of ATI at all). You must use con2fb (which accepts /dev/* names)
or con2fbmap (which accepts only number, as Geert already pointed out).
> test #2
> settings:
> PCI primary
> passed video=matrox:vesa:0x11A
> result:
> framebuffer console appeared on Matrox Head #1
> ATI - completely blank, tho still getting some sort of signal.
> Matrox Head #1 - got fb console
> Matrox Head #2 - same wavy purple pattern as in test #1
It is also expected. Secondary head displays garbage until you'll paint
something to it. 'dd if=/dev/zero of=/dev/fb2 bs=1M' should clear it,
and 'yes > /dev/fb2' should give you pink (or what's that color) screen #2.
> test #3
> settings:
> AGP primary
> no video= options
> result:
> no working console. :(
Fix your ATI...
> how much does the information about the unreadable framebuffer colors &
> patterns actually help? can one gain more information knowing that something
> showed 'black with white pinstripes' rather than 'horizontal purple
> wavy-line patterns'?
Everything works as expected. Your atyfb does not understand your ATI,
and kernel uses only first framebuffer by default. You can try
'video=map:012012012012', and then your tty1,4,7 should map to first
framebuffer, tty2,5,8 to second, and tty3,6,9 to third, so you should
see something else than garbage on secondary outputs.
Petr Vandrovec
van...@vc...
|
|
From: Geert U. <ge...@li...> - 2002-01-10 09:59:42
|
On Wed, 9 Jan 2002, Carl Wilhelm Soderstrom wrote:
> I don't have a con2fb utility, but I do have a con2fbmap utility. tried
> experimenting with it, but didn't see any results. tried (as root)
> 'con2fbmap tty1 /dev/fb1' and 'con2fbmap tty1 /dev/fb2'; but didn't see any
> results.
> I didn't have a copy of your 'matroxset' program on hand, so I didn't test
> to see what I could do with that.
Please try the plain numbers instead of the device path names, e.g.
`con2fbmap 1 1'.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
|
|
From: Carl W. S. <ch...@re...> - 2002-01-10 05:21:05
|
once a long time ago, Petr Vandrovec was kind enough to write: > In that case: > (1) Get kernel 2.4.17 > (2) Download ftp://platan.vc.cvut.cz/pub/linux/matrox-latest/mga-2.4.17.gz > (3) Apply patch (zcat mga-2.4.17.gz | (cd /usr/src/linux-2.4.17; patch -p1)) > (4) Run kernel configuration tool and answer yes for G100-G550 support, > G450 dualhead support, and for Matrox /proc interface support. You can > answer yes to something else too, but these three are mandatory. > (5) Make sure that BIOS uses ATI for its output > (6) Reboot and pray > (7) You should get nice picture on ATI (either from BIOS, vgacon or atyfb) > and nice picture on both G450 heads (though you'll see nothing on them > except color dots after bootup; con2fb & matroxset is your friend) > (8) If (7) did not happen, send me contents of all > /proc/driver/mga/fb*/* you'll find (you should find one 'bios' and > one 'pins' for each Matrox video card in your box). sorry about the delay. holidays eat into time, and fighting my way back out from under all my mailing lists took longer than I thought. :( I patched my kernel and gave it a try. here's the results of my tests: test #1 settings: PCI (ATI Xpert 98 - Mach64 chip) primary display (as set in the BIOS). no video= options result: nothing readable on any of the 3 heads. ATI - blank; tho there were some white pixels scrolling by on the left side of the screen at boot time. Matrox Head #1 - generally bluish pattern of 'snow' (in regular linear patterns). Matrox Head #2 - purplish pattern of 'wavy lines' rebooted, and did it again to see if result was repeatable. same thing happened. test #2 settings: PCI primary passed video=matrox:vesa:0x11A result: framebuffer console appeared on Matrox Head #1 ATI - completely blank, tho still getting some sort of signal. Matrox Head #1 - got fb console Matrox Head #2 - same wavy purple pattern as in test #1 logged in, and copied the contents of /proc/driver/mga/fb0/ to: www.redchrome.org/misc/bios www.redchrome.org/misc/pins I don't have a con2fb utility, but I do have a con2fbmap utility. tried experimenting with it, but didn't see any results. tried (as root) 'con2fbmap tty1 /dev/fb1' and 'con2fbmap tty1 /dev/fb2'; but didn't see any results. I didn't have a copy of your 'matroxset' program on hand, so I didn't test to see what I could do with that. test #3 settings: AGP primary no video= options result: no working console. :( ATI - no signal Matrox Head #1 - black with vertical white 'pinstripes' Matrox Head #2 - the purple wavy lines again how much does the information about the unreadable framebuffer colors & patterns actually help? can one gain more information knowing that something showed 'black with white pinstripes' rather than 'horizontal purple wavy-line patterns'? Carl Soderstrom -- Network Engineer Real-Time Enterprises (952) 943-8700 |
|
From: Sven <lu...@dp...> - 2002-01-09 15:09:44
|
On Tue, Jan 08, 2002 at 06:24:07PM -0800, Ani Joshi wrote: > > > On Tue, 8 Jan 2002, Sven wrote: > > > X works fine trough. > > > Is it because X is softbooting the card? Try removing the int10 calls > from the X driver and see if it still works, perhaps that could be it. Nope, it works like a charm on the second head also, for which the cards bios has no information whatsoever. Friendly, Sven Luther |
|
From: Sven <lu...@dp...> - 2002-01-09 09:39:32
|
On Tue, Jan 08, 2002 at 06:24:07PM -0800, Ani Joshi wrote: > > > On Tue, 8 Jan 2002, Sven wrote: > > > X works fine trough. > > > Is it because X is softbooting the card? Try removing the int10 calls > from the X driver and see if it still works, perhaps that could be it. No, X is not softbooting the card, at least i don't remember so (the bios is broken, and the driver is hand setting the correct parameters (i did write the code after all, so i guess that is what happens, unless the driver did change much since last time i looked at it). Anyway, i will try launching X on the second head, which is not initialized by the bios at all (that's why we had to sdet it up by hand, because the box would hang if we access the uninitialized second pm3 on the board). Friendly, Sven LUther |
|
From: Ani J. <aj...@sh...> - 2002-01-09 02:15:18
|
On Tue, 8 Jan 2002, Sven wrote: > X works fine trough. Is it because X is softbooting the card? Try removing the int10 calls from the X driver and see if it still works, perhaps that could be it. ani |
|
From: <da...@de...> - 2002-01-08 14:29:19
|
Hello,
Some time ago I was experimenten with double scan video modes on my
monitor, and I discovered that the Atyfb framebuffer driver didn't support
double scan or interlaced video modes. I grabbed my Mach64 manual and
started to implement it. When it worked I sent the patch to Geert
Uytterhoeven. Unfortunately Geert was busy, I did e-mail him a few times
about the patch but the answer was that he had found no time yet. Today he
asked me to post the patch to this list. Since I am not subscribed to this
list, please reply both to me and the list!
I don't know if the mailinglist accepts attachments, so I will post the
procedures that I did modify below. If you need the complete files I can
send them of course.
Ok, so here comes the code that I did modify. I have placed the code that
I modified between /* >>>>>>>>>> */ and /* ------------ */ comments.
Greetings,
Dani=EBl Mantione
My first modification was aty_var_to_crtc in atyfb_base.c:
static int aty_var_to_crtc(const struct fb_info_aty *info,
const struct fb_var_screeninfo *var,
struct crtc *crtc)
{
u32 xres, yres, vxres, vyres, xoffset, yoffset, bpp;
u32 left, right, upper, lower, hslen, vslen, sync, vmode;
u32 h_total, h_disp, h_sync_strt, h_sync_dly, h_sync_wid, h_sync_pol;
u32 v_total, v_disp, v_sync_strt, v_sync_wid, v_sync_pol, c_sync;
u32 pix_width, dp_pix_width, dp_chain_mask;
/* input */
xres =3D var->xres;
yres =3D var->yres;
vxres =3D var->xres_virtual;
vyres =3D var->yres_virtual;
xoffset =3D var->xoffset;
yoffset =3D var->yoffset;
bpp =3D var->bits_per_pixel;
left =3D var->left_margin;
right =3D var->right_margin;
upper =3D var->upper_margin;
lower =3D var->lower_margin;
hslen =3D var->hsync_len;
vslen =3D var->vsync_len;
sync =3D var->sync;
vmode =3D var->vmode;
/* convert (and round up) and validate */
xres =3D (xres+7) & ~7;
xoffset =3D (xoffset+7) & ~7;
vxres =3D (vxres+7) & ~7;
if (vxres < xres+xoffset)
vxres =3D xres+xoffset;
h_disp =3D xres/8-1;
if (h_disp > 0xff)
FAIL("h_disp too large");
h_sync_strt =3D h_disp+(right/8);
if (h_sync_strt > 0x1ff)
FAIL("h_sync_start too large");
h_sync_dly =3D right & 7;
h_sync_wid =3D (hslen+7)/8;
if (h_sync_wid > 0x1f)
FAIL("h_sync_wid too large");
h_total =3D h_sync_strt+h_sync_wid+(h_sync_dly+left+7)/8;
if (h_total > 0x1ff)
FAIL("h_total too large");
h_sync_pol =3D sync & FB_SYNC_HOR_HIGH_ACT ? 0 : 1;
if (vyres < yres+yoffset)
vyres =3D yres+yoffset;
v_disp =3D yres-1;
if (v_disp > 0x7ff)
FAIL("v_disp too large");
v_sync_strt =3D v_disp+lower;
if (v_sync_strt > 0x7ff)
FAIL("v_sync_strt too large");
v_sync_wid =3D vslen;
if (v_sync_wid > 0x1f)
FAIL("v_sync_wid too large");
v_total =3D v_sync_strt+v_sync_wid+upper;
if (v_total > 0x7ff)
FAIL("v_total too large");
v_sync_pol =3D sync & FB_SYNC_VERT_HIGH_ACT ? 0 : 1;
/* >>>>>>>>>>>> */
/* In double scan mode, the vertical parameters need to be doubled.
But in interlaced mode, there is no need to half the vertical
parameters. Code has been tested in 1024x768, 43 Hz interlaced and
640x480, 60 Hz double scan.
*/
if ((vmode & FB_VMODE_MASK) =3D=3D FB_VMODE_DOUBLE) {
v_total <<=3D 1;
v_disp <<=3D 1;
v_sync_strt <<=3D 1;
v_sync_wid <<=3D 1;
};
/* ------------ */
c_sync =3D sync & FB_SYNC_COMP_HIGH_ACT ? CRTC_CSYNC_EN : 0;
if (bpp <=3D 8) {
bpp =3D 8;
pix_width =3D CRTC_PIX_WIDTH_8BPP;
dp_pix_width =3D HOST_8BPP | SRC_8BPP | DST_8BPP | BYTE_ORDER_LSB_T=
O_MSB;
dp_chain_mask =3D 0x8080;
} else if (bpp <=3D 16) {
bpp =3D 16;
pix_width =3D CRTC_PIX_WIDTH_15BPP;
dp_pix_width =3D HOST_15BPP | SRC_15BPP | DST_15BPP |
BYTE_ORDER_LSB_TO_MSB;
dp_chain_mask =3D 0x4210;
} else if (bpp <=3D 24 && M64_HAS(INTEGRATED)) {
bpp =3D 24;
pix_width =3D CRTC_PIX_WIDTH_24BPP;
dp_pix_width =3D HOST_8BPP | SRC_8BPP | DST_8BPP | BYTE_ORDER_LSB_T=
O_MSB;
dp_chain_mask =3D 0x8080;
} else if (bpp <=3D 32) {
bpp =3D 32;
pix_width =3D CRTC_PIX_WIDTH_32BPP;
dp_pix_width =3D HOST_32BPP | SRC_32BPP | DST_32BPP |
BYTE_ORDER_LSB_TO_MSB;
dp_chain_mask =3D 0x8080;
} else
FAIL("invalid bpp");
/* >>>>>>>>>>>>>> */
// if ((vmode & FB_VMODE_MASK) !=3D FB_VMODE_NONINTERLACED)
// FAIL("invalid vmode");
/* -------------- */
/* output */
crtc->vxres =3D vxres;
crtc->vyres =3D vyres;
crtc->xoffset =3D xoffset;
crtc->yoffset =3D yoffset;
crtc->bpp =3D bpp;
crtc->h_tot_disp =3D h_total | (h_disp<<16);
crtc->h_sync_strt_wid =3D (h_sync_strt & 0xff) | (h_sync_dly<<8) |
((h_sync_strt & 0x100)<<4) | (h_sync_wid<<16) |
(h_sync_pol<<21);
crtc->v_tot_disp =3D v_total | (v_disp<<16);
crtc->v_sync_strt_wid =3D v_sync_strt | (v_sync_wid<<16) | (v_sync_pol<=
<21);
crtc->off_pitch =3D ((yoffset*vxres+xoffset)*bpp/64) | (vxres<<19);
crtc->gen_cntl =3D pix_width | c_sync | CRTC_EXT_DISP_EN | CRTC_ENABLE;
/* >>>>>>>>>>>>> */
/* Enable doublescan mode if requested */
if ((vmode & FB_VMODE_MASK) =3D=3D FB_VMODE_DOUBLE)
crtc->gen_cntl|=3DCRTC_DBL_SCAN_EN;
/* Enable interlaced mode if requested */
if ((vmode & FB_VMODE_MASK) =3D=3D FB_VMODE_INTERLACED)
crtc->gen_cntl|=3DCRTC_INTERLACE_EN;
/* ------------- */
if (M64_HAS(MAGIC_FIFO)) {
/* Not VTB/GTB */
/* FIXME: magic FIFO values */
crtc->gen_cntl |=3D aty_ld_le32(CRTC_GEN_CNTL, info) & 0x000e0000;
}
crtc->dp_pix_width =3D dp_pix_width;
crtc->dp_chain_mask =3D dp_chain_mask;
return 0;
}
The second procedure I modified was aty_crtc_to_var again in atyfb_base.c:
static int aty_crtc_to_var(const struct crtc *crtc,
struct fb_var_screeninfo *var)
{
u32 xres, yres, bpp, left, right, upper, lower, hslen, vslen, sync;
u32 h_total, h_disp, h_sync_strt, h_sync_dly, h_sync_wid, h_sync_pol;
u32 v_total, v_disp, v_sync_strt, v_sync_wid, v_sync_pol, c_sync;
u32 pix_width;
/* >>>>>>>>>>>>>>> */
u32 double_scan, interlace;
/* --------------- */
/* input */
h_total =3D crtc->h_tot_disp & 0x1ff;
h_disp =3D (crtc->h_tot_disp>>16) & 0xff;
h_sync_strt =3D (crtc->h_sync_strt_wid & 0xff) |
((crtc->h_sync_strt_wid>>4) & 0x100);
h_sync_dly =3D (crtc->h_sync_strt_wid>>8) & 0x7;
h_sync_wid =3D (crtc->h_sync_strt_wid>>16) & 0x1f;
h_sync_pol =3D (crtc->h_sync_strt_wid>>21) & 0x1;
v_total =3D crtc->v_tot_disp & 0x7ff;
v_disp =3D (crtc->v_tot_disp>>16) & 0x7ff;
v_sync_strt =3D crtc->v_sync_strt_wid & 0x7ff;
v_sync_wid =3D (crtc->v_sync_strt_wid>>16) & 0x1f;
v_sync_pol =3D (crtc->v_sync_strt_wid>>21) & 0x1;
c_sync =3D crtc->gen_cntl & CRTC_CSYNC_EN ? 1 : 0;
pix_width =3D crtc->gen_cntl & CRTC_PIX_WIDTH_MASK;
/* >>>>>>>>>>>>>>> */
double_scan =3D crtc->gen_cntl & CRTC_DBL_SCAN_EN;
interlace =3D crtc->gen_cntl & CRTC_INTERLACE_EN;
/* --------------- */
/* convert */
xres =3D (h_disp+1)*8;
yres =3D v_disp+1;
left =3D (h_total-h_sync_strt-h_sync_wid)*8-h_sync_dly;
right =3D (h_sync_strt-h_disp)*8+h_sync_dly;
hslen =3D h_sync_wid*8;
upper =3D v_total-v_sync_strt-v_sync_wid;
lower =3D v_sync_strt-v_disp;
vslen =3D v_sync_wid;
sync =3D (h_sync_pol ? 0 : FB_SYNC_HOR_HIGH_ACT) |
(v_sync_pol ? 0 : FB_SYNC_VERT_HIGH_ACT) |
(c_sync ? FB_SYNC_COMP_HIGH_ACT : 0);
switch (pix_width) {
#if 0
case CRTC_PIX_WIDTH_4BPP:
bpp =3D 4;
var->red.offset =3D 0;
var->red.length =3D 8;
var->green.offset =3D 0;
var->green.length =3D 8;
var->blue.offset =3D 0;
var->blue.length =3D 8;
var->transp.offset =3D 0;
var->transp.length =3D 0;
break;
#endif
case CRTC_PIX_WIDTH_8BPP:
bpp =3D 8;
var->red.offset =3D 0;
var->red.length =3D 8;
var->green.offset =3D 0;
var->green.length =3D 8;
var->blue.offset =3D 0;
var->blue.length =3D 8;
var->transp.offset =3D 0;
var->transp.length =3D 0;
break;
case CRTC_PIX_WIDTH_15BPP: /* RGB 555 */
bpp =3D 16;
var->red.offset =3D 10;
var->red.length =3D 5;
var->green.offset =3D 5;
var->green.length =3D 5;
var->blue.offset =3D 0;
var->blue.length =3D 5;
var->transp.offset =3D 0;
var->transp.length =3D 0;
break;
#if 0
case CRTC_PIX_WIDTH_16BPP: /* RGB 565 */
bpp =3D 16;
var->red.offset =3D 11;
var->red.length =3D 5;
var->green.offset =3D 5;
var->green.length =3D 6;
var->blue.offset =3D 0;
var->blue.length =3D 5;
var->transp.offset =3D 0;
var->transp.length =3D 0;
break;
#endif
case CRTC_PIX_WIDTH_24BPP: /* RGB 888 */
bpp =3D 24;
var->red.offset =3D 16;
var->red.length =3D 8;
var->green.offset =3D 8;
var->green.length =3D 8;
var->blue.offset =3D 0;
var->blue.length =3D 8;
var->transp.offset =3D 0;
var->transp.length =3D 0;
break;
case CRTC_PIX_WIDTH_32BPP: /* ARGB 8888 */
bpp =3D 32;
var->red.offset =3D 16;
var->red.length =3D 8;
var->green.offset =3D 8;
var->green.length =3D 8;
var->blue.offset =3D 0;
var->blue.length =3D 8;
var->transp.offset =3D 24;
var->transp.length =3D 8;
break;
default:
FAIL("Invalid pixel width");
}
/* output */
var->xres =3D xres;
var->yres =3D yres;
var->xres_virtual =3D crtc->vxres;
var->yres_virtual =3D crtc->vyres;
var->bits_per_pixel =3D bpp;
var->xoffset =3D crtc->xoffset;
var->yoffset =3D crtc->yoffset;
var->left_margin =3D left;
var->right_margin =3D right;
var->upper_margin =3D upper;
var->lower_margin =3D lower;
var->hsync_len =3D hslen;
var->vsync_len =3D vslen;
var->sync =3D sync;
var->vmode =3D FB_VMODE_NONINTERLACED;
/* >>>>>>>>>>>> */
/* In double scan mode, the vertical parameters are doubled, so we need=
to
half them to get the right values.
In interlaced mode the values are already correct, so no correction =
is
necessary.
Code has been tested in 1024x768, 43 Hz interlaced and 640x480,
60Hz double scan.
*/
if (interlace)
var->vmode =3D FB_VMODE_INTERLACED;
if (double_scan) {
var->vmode =3D FB_VMODE_DOUBLE;
var->yres>>=3D1;
var->upper_margin>>=3D1;
var->lower_margin>>=3D1;
var->vsync_len>>=3D1;
};
/* ------------ */
return 0;
}
Lastly, a small modification in aty_set_cursor in mach64_cursor.c:
static void
aty_set_cursor(struct fb_info_aty *fb, int on)
{
struct atyfb_par *par =3D &fb->current_par;
struct aty_cursor *c =3D fb->cursor;
u16 xoff, yoff;
int x, y;
if (!c)
return;
#ifdef __sparc__
if (fb->mmaped && (!fb->fb_info.display_fg
|| fb->fb_info.display_fg->vc_num =3D=3D fb->vtconsole))
return;
#endif
if (on) {
x =3D c->pos.x - c->hot.x - par->crtc.xoffset;
if (x < 0) {
xoff =3D -x;
x =3D 0;
} else {
xoff =3D 0;
}
y =3D c->pos.y - c->hot.y - par->crtc.yoffset;
if (y < 0) {
yoff =3D -y;
y =3D 0;
} else {
yoff =3D 0;
}
=09=09/* >>>>>>>>>> */
/* In doublescan mode, the cursor location also needs to be
doubled. */
if (par->crtc.gen_cntl & CRTC_DBL_SCAN_EN)
y<<=3D1;
=09=09/* ---------- */
wait_for_fifo(4, fb);
aty_st_le32(CUR_OFFSET, (c->offset >> 3) + (yoff << 1), fb)=
;
aty_st_le32(CUR_HORZ_VERT_OFF,
((u32)(64 - c->size.y + yoff) << 16) | xoff, fb=
);
aty_st_le32(CUR_HORZ_VERT_POSN, ((u32)y << 16) | x, fb);
aty_st_le32(GEN_TEST_CNTL, aty_ld_le32(GEN_TEST_CNTL, fb)
| HWCURSOR_ENABLE, f=
b);
} else {
wait_for_fifo(1, fb);
aty_st_le32(GEN_TEST_CNTL,
aty_ld_le32(GEN_TEST_CNTL, fb) & ~HWCURSOR_ENAB=
LE,
fb);
}
if (fb->blitter_may_be_busy)
wait_for_idle(fb);
}
|
|
From: Sven <lu...@dp...> - 2002-01-08 14:11:06
|
On Tue, Jan 08, 2002 at 03:06:07PM +0100, Geert Uytterhoeven wrote: > On Tue, 8 Jan 2002, Sven wrote: > > Saturday, i upgraded my box from a K6-2 on an ali chipset wich i gave my > > little brother to a duron 1000 on a sis 735 chipset, rebooted the same 2.4.17 > > kernel i have been using without problem with pm3fb, and ... no more pm3fb, > > only a black screen with some very dark grey garbage. X launched ok though, so > > i rebuilt the kernel switching the ali agpgart and ide modules with the sis > > ones, and maybe some other such stuff, but no changes. > > Dumb question, but does the SIS have a builtin graphics chip? No, it does not, ... (only the sys xx0 have, not the xx5 chips). X works fine trough. Will provide more debug info tommorow ... Friendly, Sven LUther |
|
From: Geert U. <ge...@li...> - 2002-01-08 14:06:49
|
On Tue, 8 Jan 2002, Sven wrote:
> Saturday, i upgraded my box from a K6-2 on an ali chipset wich i gave my
> little brother to a duron 1000 on a sis 735 chipset, rebooted the same 2.4.17
> kernel i have been using without problem with pm3fb, and ... no more pm3fb,
> only a black screen with some very dark grey garbage. X launched ok though, so
> i rebuilt the kernel switching the ali agpgart and ide modules with the sis
> ones, and maybe some other such stuff, but no changes.
Dumb question, but does the SIS have a builtin graphics chip?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
|
754 messages has been excluded from this view by a project administrator.
