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: James S. <jsi...@tr...> - 2002-05-29 22:43:53
|
> > Due to a error with merging some stuff from a older DJ tree. I fixed it
> > in the fbdev BK repository.
>
> They haven't *been* in any DJ tree.
Looking threw the many patches I have from people I did grab it from
patch-2.5.15-rmk1. It is right above the fbcmap.c fix which I did need.
That is where I go it from. Thank you for that fix.
While grabbing that fix I noticed what a appeared to be a simple two
line fix for the cyber2000fb driver. Actually I was tempted to port the
whole driver over to the new api but I didn't because I feared you be
ticked off. Especially since I don't have the hardware. The only drivers I
have ported over are the ones that are really simple. I touched the
anakin driver because of this reason. The complex one where I don't have
the hardware I don't touch. Now that we have enough functionally drivers
people can see the new changes needed to be done.
> Why the fuck should I go around finding and testing peoples trees when I
> haven't submitted the stuff to them?
Look here. I'm not looking for trouble or to upset anyone. I know alot
of the fbdev driver maintainers are too busy to properly maintain the
drivers. Several have told me this. Or the drivers have been abandon.
Plus the docs have been shotty for porting to the new api. I am willing to
do extra work and port these drivers to save the maintainers time. I'm
not going to do a perfect port but I do hope what work I did do will help
them out.
I do admit and apologize for not properly saying which drivers have
been altered. I will make a special note of doing that in the future.
Especially since very few actually look at my patches.
|
|
From: Russell K. <rm...@ar...> - 2002-05-29 20:47:57
|
On Wed, May 29, 2002 at 01:44:12PM -0700, James Simmons wrote:
> > This is completely wrong - the driver has been tested NOT to work on
> > the Integraphics 1682. As such, please do uncomment these lines.
>
> Due to a error with merging some stuff from a older DJ tree. I fixed it
> in the fbdev BK repository.
They haven't *been* in any DJ tree.
> > In addition, I'm disappointed that no one forwarded the patch for
> > maintainer approval PRIOR to submitting it to Linus.
>
> I'm even more disappointed that some people DONT test my patches especially
> when I announce them and usually wait about 5 days before pushing them to
> Linus. Some of the changes I have done have been sitting around for months
> in the DJ tree. The good news is that people can now look at skeletonfb.c
> to see how to port the fbdev drivers to the new api. Of course I have a
> feeling most will not bother so I will have to do it for them.
Why the fuck should I go around finding and testing peoples trees when I
haven't submitted the stuff to them? *YOU* shouldn't go around randomly
pulling stuff from maintainers trees without first asking them why the
change hasn't been submitted.
I'm not talking about general maintainence of the cyber2000fb driver here,
or general "keep it working" type changes. I'm talking about a blatent
"take the version from the rmk patch and submit it to Linus without telling
the maintainer of the code you're buggering with" attitude here.
--
Russell King (rm...@ar...) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
|
|
From: James S. <jsi...@tr...> - 2002-05-29 20:44:26
|
> This is completely wrong - the driver has been tested NOT to work on > the Integraphics 1682. As such, please do uncomment these lines. Due to a error with merging some stuff from a older DJ tree. I fixed it in the fbdev BK repository. > In addition, I'm disappointed that no one forwarded the patch for > maintainer approval PRIOR to submitting it to Linus. I'm even more disappointed that some people DONT test my patches especially when I announce them and usually wait about 5 days before pushing them to Linus. Some of the changes I have done have been sitting around for months in the DJ tree. The good news is that people can now look at skeletonfb.c to see how to port the fbdev drivers to the new api. Of course I have a feeling most will not bother so I will have to do it for them. |
|
From: James S. <jsi...@tr...> - 2002-05-28 18:10:02
|
Hi! Could you merge the latest stuff in the fbdev BK tree. It has various fixes and ports over ot the new api. Also a few new drivers. http://fbdev.bkbits.net:8080/fbdev-2.5 or a traditional diff at http://www.transvirtual.com/~jsimmons/fbdev.diff P.S To the general list. The company I work for appears to be going under. So if anyone is looking for a kernel developer drop me a email. . --- |o_o | |:_/ | Give Micro$oft the Bird!!!! // \ \ Use Linux!!!! (| | ) /'_ _/`\ ___)=(___/ |
|
From: James S. <jsi...@tr...> - 2002-05-28 17:29:21
|
>> Hi, >> >> I have an unusual problem with cfb_imageblit. I'm not too sure if this >> is unique to my system. I get garbage pixels. For example the >> underscore character (_) appears like this magnified: > >Didn't look carefully enough, I found the problem. > >Tony > >--- cfbimgblt.c-orig Fri May 24 15:51:13 2002 >+++ cfbimgblt.c Fri May 24 15:51:28 2002 >@@ -105,7 +105,7 @@ > fb_writel((mask & eorx)^bgx, dst); > dst++; > } >- l =- pad; >+ l -= pad; > dst1 += p->fix.line_length; > } > } Great job finding that bug :-) I applied it to my BK tree. I plan to push things to Linus now. |
|
From: Antonino D. <ad...@po...> - 2002-05-24 23:23:45
|
On Fri, 2002-05-24 at 21:19, Antonino Daplas wrote: > Hi, > > I have an unusual problem with cfb_imageblit. I'm not too sure if this > is unique to my system. I get garbage pixels. For example the > underscore character (_) appears like this magnified: Didn't look carefully enough, I found the problem. Tony --- cfbimgblt.c-orig Fri May 24 15:51:13 2002 +++ cfbimgblt.c Fri May 24 15:51:28 2002 @@ -105,7 +105,7 @@ fb_writel((mask & eorx)^bgx, dst); dst++; } - l =- pad; + l -= pad; dst1 += p->fix.line_length; } } |
|
From: Louis G. <lou...@be...> - 2002-05-24 18:51:53
|
but the dvi connection for LCDs are supported, right? --Lou On Fri, 2002-05-24 at 04:40, Ani Joshi wrote: > > Yes, they are supported in current 2.4 kernel. However dualhead with > these chips (and VE) will only be supported in future 2.5 kernels. > > > ani > > On 23 May 2002, Louis Garcia wrote: > > > Does the radeonfb (kernel-2.4.18) support the 7500 or 8500 chip? > > > > Thanks, --Lou > > > > > > > > _______________________________________________________________ > > > > Don't miss the 2002 Sprint PCS Application Developer's Conference > > August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm > > > > _______________________________________________ > > Linux-fbdev-devel mailing list > > Lin...@li... > > https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel > > > |
|
From: Andrey U. <dr...@rt...> - 2002-05-24 17:31:21
|
On Fri, May 24, 2002 at 09:19:09PM +0800, Antonino Daplas wrote: > I have an unusual problem with cfb_imageblit. I'm not too sure if this > is unique to my system. I get garbage pixels. For example the > underscore character (_) appears like this magnified: > > 01234567 > 0 > . > . > . > > 13 ******* > 14 * > 15 ** <-- belongs to apostrophe char > > It seems that the image is off by one bit and one row of pixels so it > also includes the first row of pixels of the next character (`) in > fontdata. > Any comments? Some time ago I had the same problem even under X Window and Window$. And it seems it's problem with hardware. Try to reduce system bus frequency. -- with best regards, Andrey Ulanov. dr...@rt... |
|
From: Antonino D. <ad...@po...> - 2002-05-24 13:18:10
|
Hi,
I have an unusual problem with cfb_imageblit. I'm not too sure if this
is unique to my system. I get garbage pixels. For example the
underscore character (_) appears like this magnified:
01234567
0
.
.
.
13 *******
14 *
15 ** <-- belongs to apostrophe char
It seems that the image is off by one bit and one row of pixels so it
also includes the first row of pixels of the next character (`) in
fontdata.
Looking at the code in cfbimgblt.c, I cannot find any obvious mistake,
so I made a dump of the variables during the loop iteration. Here's
what I get:
/* bpp = 8, 8x16 font, caret (^) bitmap */
pad 0 /* no excess pixels */
10 /* initial content of *src */
i 0, j 2, k 4, l 7
i 0, j 2, k 3, l 6
i 0, j 2, k 2, l 5
i 0, j 2, k 1, l 4
i 0, j 1, k 4, l 3
i 0, j 1, k 3, l 2
i 0, j 1, k 2, l 1
i 0, j 1, k 1, l 0 /* everything is okay until ... */
38 l 7 /* l = 7, and new content of *src = 0x38 */
i 1, j 2, k 4, l 0 <--- l = 0?!?! I'm confused here ...
6c l 7 /* so, src is again updated (*src = 0x6c)*/
i 1, j 2, k 3, l 7 /* at this point, we're off by 9 bits */
i 1, j 2, k 2, l 6
i 1, j 2, k 1, l 5
i 1, j 1, k 4, l 4
i 1, j 1, k 3, l 3
i 1, j 1, k 2, l 2
i 1, j 1, k 1, l 1
i 2, j 2, k 4, l 0
c6 l 7
i 2, j 2, k 3, l 7 /* the algo is now doing what it should */
i 2, j 2, k 2, l 6 /* and continues to do so till the end */
i 2, j 2, k 1, l 5
i 2, j 1, k 4, l 4
i 2, j 1, k 3, l 3
i 2, j 1, k 2, l 2
i 2, j 1, k 1, l 1
i 3, j 2, k 4, l 0
0 l 7
<<< cut >>>
I'm not too sure why 'l' did not retain it's assignment. This happens
only after the first iteration of 'i'. I've tried using different
compilers (gcc-2.95.3 and gcc-3.0.4). I've changed the declaration of
'l' to static and volatile, and changed its placement, but I still get
the same result.
Just to prove that cfb_imageblit is correct, I used 'k' and 'j' instead
of 'l' in the test_bit() part. It's slower, but it proves that the
algorithm of cfb_imageblit is correct.
for (i = 0; i < image->height; i++) {
dst = (unsigned long *) dst1;
for (j = image->width/ppw; j > 0; j--) {
mask = 0;
for (k = ppw; k > 0; k--) {
if (test_bit((j*ppw - (ppw-k) - 1), src))
mask |= (tmp >> (p->var.bits_per_pixel*(k-1)));
}
fb_writel((mask & eorx)^bgx, dst);
dst++;
}
src++;
l =- pad;
dst1 += p->fix.line_length;
}
Any comments?
Tony
|
|
From: Ani J. <aj...@sh...> - 2002-05-24 08:31:14
|
Yes, they are supported in current 2.4 kernel. However dualhead with these chips (and VE) will only be supported in future 2.5 kernels. ani On 23 May 2002, Louis Garcia wrote: > Does the radeonfb (kernel-2.4.18) support the 7500 or 8500 chip? > > Thanks, --Lou > > > > _______________________________________________________________ > > Don't miss the 2002 Sprint PCS Application Developer's Conference > August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm > > _______________________________________________ > Linux-fbdev-devel mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel > |
|
From: Louis G. <lou...@be...> - 2002-05-23 20:14:09
|
Does the radeonfb (kernel-2.4.18) support the 7500 or 8500 chip? Thanks, --Lou |
|
From: James S. <jsi...@tr...> - 2002-05-22 16:54:12
|
Hi! I just ported over a few driver to the new api. I also included a few bug fixes as well as a few new drivers. Please try it out and send me any patches. Once the testing is done I will ask Linus to included into his tree. If you look at skeletonfb.c you will see actual info on the new api to help you port it over to the new api. BK: http://fbdev.bkbits.net:8080/fbdev-2.5 Diff: http://www.transvirtual.com/~jsimmons/fbdev.diff P.S Yes with with new api I haven't finished the drawing penguin code so you don't see a penguin yet. I will but I figured the new api is more important. . --- |o_o | |:_/ | Give Micro$oft the Bird!!!! // \ \ Use Linux!!!! (| | ) /'_ _/`\ ___)=(___/ |
|
From: Ghozlane T. <gh...@sy...> - 2002-05-17 19:09:22
|
On Friday 17 May 2002 14:16, James Simmons wrote: > Does anyone have a framebuffer drawing program that dfisplays the penguin > at any color depth? IIRC one of the tests from fbtest does that ... (somewhere in linux-fbdev CVS) ghoz |
|
From: James S. <jsi...@tr...> - 2002-05-17 18:16:09
|
Does anyone have a framebuffer drawing program that dfisplays the penguin at any color depth? . --- |o_o | |:_/ | Give Micro$oft the Bird!!!! // \ \ Use Linux!!!! (| | ) /'_ _/`\ ___)=(___/ |
|
From: Michel <mi...@da...> - 2002-05-14 17:40:56
|
On Tue, 2002-05-14 at 14:11, Frederick Lefebvre wrote: > Does anybody ever had succes switching fbdev resolution while running a > X server. I am running Xfbdev (from kdrive) over a fbdev and I get > screen corruption everytime I switch resolution.=20 Why do you expect changing things behind the X server's back to work? Can't Xfbdev use several resolutions and switch between them, like the 'real' XFree86 server can? --=20 Earthling Michel D=E4nzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast |
|
From: Frederick L. <fle...@ir...> - 2002-05-14 12:07:46
|
Hello, Does anybody ever had succes switching fbdev resolution while running a X server. I am running Xfbdev (from kdrive) over a fbdev and I get screen corruption everytime I switch resolution. Thank's Frederick Lefebvre fle...@ir... |
|
From: Miles L. <mi...@me...> - 2002-05-13 00:52:01
|
Hmm. I just realised may still not have given enough information. Here is a bit more. vendor_id : AuthenticAMD cpu family : 6 model : 2 model name : AMD Athlon(tm) Processor cpu MHz : 848.383 00:00.0 Host bridge: Advanced Micro Devices [AMD] AMD-751 [Irongate] System Controller (rev 25) Flags: bus master, medium devsel, latency 64 Memory at f8000000 (32-bit, prefetchable) [size=64M] Memory at fc9ff000 (32-bit, prefetchable) [size=4K] I/O ports at ffe4 [disabled] [size=4] Capabilities: <available only to root> 00:01.0 PCI bridge: Advanced Micro Devices [AMD] AMD-751 [Irongate] AGP Bridge (rev 01) (prog-if 00 [Normal decode]) Flags: bus master, 66Mhz, medium devsel, latency 64 Bus: primary=00, secondary=01, subordinate=01, sec-latency=64 I/O behind bridge: 0000e000-0000efff Memory behind bridge: fca00000-feafffff Prefetchable memory behind bridge: e4800000-f48fffff 00:07.0 ISA bridge: Advanced Micro Devices [AMD] AMD-756 [Viper] ISA (rev 01) Flags: bus master, medium devsel, latency 0 00:07.1 IDE interface: Advanced Micro Devices [AMD] AMD-756 [Viper] IDE (rev 03) (prog-if 8a [Master SecP PriP]) Flags: bus master, medium devsel, latency 64 I/O ports at cb00 [size=16] 00:07.3 Bridge: Advanced Micro Devices [AMD] AMD-756 [Viper] ACPI (rev 03) Flags: medium devsel 00:07.4 USB Controller: Advanced Micro Devices [AMD] AMD-756 [Viper] USB (rev 06) (prog-if 10 [OHCI]) Flags: bus master, medium devsel, latency 16, IRQ 10 Memory at febfe000 (32-bit, non-prefetchable) [size=4K] 00:0f.0 SCSI storage controller: Adaptec AHA-2930CU (rev 03) Subsystem: Adaptec: Unknown device 3869 Flags: bus master, medium devsel, latency 64, IRQ 11 I/O ports at f800 [disabled] [size=256] Memory at febff000 (32-bit, non-prefetchable) [size=4K] Expansion ROM at febe0000 [disabled] [size=64K] Capabilities: <available only to root> 00:11.0 USB Controller: NEC Corporation USB (rev 41) (prog-if 10 [OHCI]) Subsystem: NEC Corporation USB Flags: bus master, medium devsel, latency 40, IRQ 11 Memory at febfb000 (32-bit, non-prefetchable) [size=4K] Capabilities: <available only to root> 00:11.1 USB Controller: NEC Corporation USB (rev 41) (prog-if 10 [OHCI]) Subsystem: NEC Corporation USB Flags: bus master, medium devsel, latency 40, IRQ 5 Memory at febfc000 (32-bit, non-prefetchable) [size=4K] Capabilities: <available only to root> 00:11.2 USB Controller: NEC Corporation: Unknown device 00e0 (rev 01) (prog-if 20) Subsystem: NEC Corporation: Unknown device 00e0 Flags: bus master, medium devsel, latency 64, IRQ 9 Memory at febfdf00 (32-bit, non-prefetchable) [size=256] Capabilities: <available only to root> 00:12.0 Multimedia audio controller: Creative Labs SB Live! EMU10000 (rev 07) Subsystem: Creative Labs CT4831 SBLive! Value Flags: bus master, medium devsel, latency 64, IRQ 5 I/O ports at ff80 [size=32] Capabilities: <available only to root> 00:12.1 Input device controller: Creative Labs SB Live! (rev 07) Subsystem: Creative Labs Gameport Joystick Flags: bus master, medium devsel, latency 64 I/O ports at fff0 [size=8] Capabilities: <available only to root> 00:13.0 Ethernet controller: 3Com Corporation 3c905C-TX [Fast Etherlink] (rev 78) Subsystem: 3Com Corporation 3C905C-TX Fast Etherlink for PC Management NIC Flags: bus master, medium devsel, latency 64, IRQ 9 I/O ports at fc00 [size=128] Memory at febfde80 (32-bit, non-prefetchable) [size=128] Expansion ROM at febc0000 [disabled] [size=128K] Capabilities: <available only to root> 00:14.0 CardBus bridge: Ricoh Co Ltd RL5c478 (rev 03) Flags: medium devsel Memory at 10000000 (32-bit, non-prefetchable) [disabled] [size=4K] Bus: primary=00, secondary=02, subordinate=05, sec-latency=0 I/O window 0: 00000000-00000003 [disabled] I/O window 1: 00000000-00000003 [disabled] 16-bit legacy interface ports at 0001 00:14.1 CardBus bridge: Ricoh Co Ltd RL5c478 (rev 03) Flags: medium devsel Memory at 10001000 (32-bit, non-prefetchable) [disabled] [size=4K] Bus: primary=00, secondary=06, subordinate=09, sec-latency=0 I/O window 0: 00000000-00000003 [disabled] I/O window 1: 00000000-00000003 [disabled] 16-bit legacy interface ports at 0001 |
|
From: Miles L. <mi...@me...> - 2002-05-12 18:27:05
|
On Sun, 2002-05-12 at 10:34, Ani Joshi wrote: > What video board and arch (i'm assuming i386)? May 12 07:08:53 turbulence kernel: Linux version 2.4.19-pre8-ac2 (ro...@tu...) (gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-98)) #1 Sun May 12 00:41:02 PDT 2002 May 12 07:08:54 turbulence kernel: Kernel command line: ro root=/dev/hda6 hdd=ide-scsi console=ttyS0,38400 console=tty0 video=riva:1600x1200-16 May 12 07:08:54 turbulence kernel: Local APIC disabled by BIOS -- reenabling. May 12 07:08:54 turbulence kernel: Found and enabled local APIC! May 12 07:08:54 turbulence kernel: Initializing CPU#0 May 12 07:08:54 turbulence kernel: CPU: Before vendor init, caps: 0183fbff c1c3fbff 00000000, vendor = 2 May 12 07:08:54 turbulence kernel: CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) May 12 07:08:54 turbulence kernel: CPU: L2 Cache: 512K (64 bytes/line) May 12 07:08:54 turbulence kernel: CPU: After vendor init, caps: 0183fbff c1c3fbff 00000000 00000000 May 12 07:08:54 turbulence kernel: Intel machine check architecture supported. May 12 07:08:54 turbulence kernel: Intel machine check reporting enabled on CPU#0. May 12 07:08:54 turbulence kernel: CPU: After generic, caps: 0183fbff c1c3fbff 00000000 00000000 May 12 07:08:54 turbulence kernel: CPU: Common caps: 0183fbff c1c3fbff 00000000 00000000 May 12 07:08:56 turbulence kernel: rivafb: RIVA MTRR set to ON May 12 07:08:57 turbulence kernel: rivafb: PCI nVidia NV10 framebuffer ver 0.9.3 (GeForce-DDR, 32MB @ 0xE8000000) 01:05.0 VGA compatible controller: nVidia Corporation GeForce 256 DDR (rev 10) (prog-if 00 [VGA]) Subsystem: VISIONTEK: Unknown device 000b Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 64 (1250ns min, 250ns max) Interrupt: pin A routed to IRQ 11 Region 0: Memory at fd000000 (32-bit, non-prefetchable) [size=16M] Region 1: Memory at e8000000 (32-bit, prefetchable) [size=128M] Expansion ROM at feaf0000 [disabled] [size=64K] Capabilities: [60] Power Management version 1 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [44] AGP version 2.0 Status: RQ=31 SBA- 64bit- FW+ Rate=x1,x2 Command: RQ=0 SBA- AGP- 64bit- FW- Rate=<none> > > > ani > > On Sat, 11 May 2002, Miles Lane wrote: > > > I am running development kernel 2.5.15 and am having some > > trouble getting rivafb to display in the correct mode. > > > > After booting with "video=riva:1600x1200-16", fbset says: > > > > mode "1600x1200-60" > > # D: 162.022 MHz, H: 75.010 kHz, V: 60.008 Hz > > geometry 1600 1200 1600 1200 16 > > timings 6172 304 64 46 1 192 3 > > hsync high > > vsync high > > accel true > > rgba 5/11,6/5,5/0,0/0 > > endmode > > > > But the Tux logo is all purple. After running fbset -a "1600x1200-76", > > I seem to have the correct mode: > > > > mode "1600x1200-76" > > # D: 197.981 MHz, H: 95.183 kHz, V: 76.146 Hz > > geometry 1600 1200 1600 1200 8 > > timings 5051 304 40 42 3 136 5 > > accel true > > rgba 8/0,8/0,8/0,0/0 > > endmode > > > > What do I need to change about my append= line in order to get > > the corrent mode set at boot time or is this a bug in the > > rivafb code in 2.5.15? > > > > > > _______________________________________________________________ > > > > Have big pipes? SourceForge.net is looking for download mirrors. We supply > > the hardware. You get the recognition. Email Us: ban...@so... > > _______________________________________________ > > Linux-fbdev-devel mailing list > > Lin...@li... > > https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel > > > |
|
From: Ani J. <aj...@sh...> - 2002-05-12 17:23:50
|
What video board and arch (i'm assuming i386)? ani On Sat, 11 May 2002, Miles Lane wrote: > I am running development kernel 2.5.15 and am having some > trouble getting rivafb to display in the correct mode. > > After booting with "video=riva:1600x1200-16", fbset says: > > mode "1600x1200-60" > # D: 162.022 MHz, H: 75.010 kHz, V: 60.008 Hz > geometry 1600 1200 1600 1200 16 > timings 6172 304 64 46 1 192 3 > hsync high > vsync high > accel true > rgba 5/11,6/5,5/0,0/0 > endmode > > But the Tux logo is all purple. After running fbset -a "1600x1200-76", > I seem to have the correct mode: > > mode "1600x1200-76" > # D: 197.981 MHz, H: 95.183 kHz, V: 76.146 Hz > geometry 1600 1200 1600 1200 8 > timings 5051 304 40 42 3 136 5 > accel true > rgba 8/0,8/0,8/0,0/0 > endmode > > What do I need to change about my append= line in order to get > the corrent mode set at boot time or is this a bug in the > rivafb code in 2.5.15? > > > _______________________________________________________________ > > Have big pipes? SourceForge.net is looking for download mirrors. We supply > the hardware. You get the recognition. Email Us: ban...@so... > _______________________________________________ > Linux-fbdev-devel mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel > |
|
From: Miles L. <mi...@me...> - 2002-05-12 08:02:25
|
On Sat, 2002-05-11 at 08:50, Jeff Garzik wrote: > Miles Lane wrote: > > > I am running development kernel 2.5.15 and am having some > > trouble getting rivafb to display in the correct mode. > > Does 2.4.19-pre8 work for you? Yes, 2.4.19-pre8-ac2 fails in exactly the same way. Miles |
|
From: Jeff G. <jg...@ma...> - 2002-05-11 15:51:57
|
Miles Lane wrote: > I am running development kernel 2.5.15 and am having some > trouble getting rivafb to display in the correct mode. Does 2.4.19-pre8 work for you? |
|
From: <il...@pi...> - 2002-05-11 15:23:52
|
Hi,
I have a Dell Inspiron 4000 laptop with an 8MB ATI Rage Mobility M3
video card with the following lspci output:
01:00.0 VGA compatible controller: ATI Technologies Inc Rage Mobility
M3 AGP 2x (rev 02) (prog-if 00 [VGA])
Subsystem: Dell Computer Corporation: Unknown device 00b0
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping+ SERR- FastB2B-
Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=3Dmedium
>TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 32 (2000ns min), cache line size 08
Interrupt: pin A routed to IRQ 11
Region 0: Memory at f4000000 (32-bit, prefetchable) [size=3D64M]
Region 1: I/O ports at ec00 [size=3D256]
Region 2: Memory at fdffc000 (32-bit, non-prefetchable) [size=3D16K]
Expansion ROM at <unassigned> [disabled] [size=3D128K]
Capabilities: [50] AGP version 2.0
Status: RQ=3D31 SBA+ 64bit- FW- Rate=3Dx1,x2
Command: RQ=3D0 SBA+ AGP- 64bit- FW- Rate=3D<none>
Capabilities: [5c] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=3D0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=3D0 DScale=3D0 PME-
The LCD display is a 1400x1050 panel, identified by XFree86 as
follows:
(II) R128(0): Panel size: 1400x1050
(II) R128(0): Panel ID: Samsung LTN141P2=20=20=20=20=20=20=20=20
(II) R128(0): Panel Type: Color, Single, TFT
(II) R128(0): Panel Interface: LVDS
When I load the aty128fb module (I've tried with several kernels, most
recently 2.5.13 with the fbdev patch posted on lkml just after its
release), the screeen goes black and flickery with a thin,
multicolored horizontal line about 1cm from the bottom. dmesg says
this about the card when the module is loaded:
PCI: Found IRQ 11 for device 01:00.0
aty128fb: Rage128 BIOS not located. Guessing...
aty128fb: Rage Mobility M3 (AGP) [chip rev 0x0] 8M 128-bit SDR SGRAM (=
1:1)
Console: switching to colour frame buffer device 80x30
fb0: ATY Rage128 frame buffer device on PCI
aty128fb: Rage128 MTRR set to ON
If I switch resolutions with fbset (logged in remotely), the display
goes completely weird, it looks like if some liquid with bright green
and purple "edges" flows from the top and the bottom of the screen,
about 5cm from the right edge. This goes on until the left half of the
screen is green and purple, then it fades to black and white. If I
switch back to 640x480@60Hz, it goes back to the initial black state.
If I log in remotely and start X (or switch back to the X VT, if X
was already running), the screen has 5-15cm wide bands containing
various misplaced and corrupted (except one of the bands) parts of the
image. If I switch resolutions and switch between stretched and
centered mode (Fn-F7), I can get it to look right (but still
flickering) in 800x600 and 640x480.
I hope someone can make some sense of this. I am of course more than
willing to test patches and assist in debugging.
=2D-=20
Dagfinn I. Manns=C3=A5ker
aka. Ilmari
|
|
From: Miles L. <mi...@me...> - 2002-05-11 15:15:53
|
I am running development kernel 2.5.15 and am having some
trouble getting rivafb to display in the correct mode.
After booting with "video=riva:1600x1200-16", fbset says:
mode "1600x1200-60"
# D: 162.022 MHz, H: 75.010 kHz, V: 60.008 Hz
geometry 1600 1200 1600 1200 16
timings 6172 304 64 46 1 192 3
hsync high
vsync high
accel true
rgba 5/11,6/5,5/0,0/0
endmode
But the Tux logo is all purple. After running fbset -a "1600x1200-76",
I seem to have the correct mode:
mode "1600x1200-76"
# D: 197.981 MHz, H: 95.183 kHz, V: 76.146 Hz
geometry 1600 1200 1600 1200 8
timings 5051 304 40 42 3 136 5
accel true
rgba 8/0,8/0,8/0,0/0
endmode
What do I need to change about my append= line in order to get
the corrent mode set at boot time or is this a bug in the
rivafb code in 2.5.15?
|
|
From: Michel <mi...@da...> - 2002-05-07 22:51:09
|
On Tue, 2002-05-07 at 10:00, Geert Uytterhoeven wrote:=20 > > > If it's really a problem, maybe we could figure out a way to detect w= hen > > > it's safe to optimize stuff away or as a last resort make it an optio= n? > > >=20 > > I think if the gen_* interface is to be adopted, it will become a > > problem. Detection is the best solution, but right now X and DRI do not > > know that fb even exist so we can't get X to detect fb unless we > > persuade the X people to do that. I have tried X detection before by > > checking the previous console number. If the previous number is not a > > valid console, we can presume that a non-console app used that. But > > this is not clean and there are too many conditions where this check > > will fail. But then, I really don't understand the underlying console > > interface, so an easier and more effective way may exist that I don't > > know about. >=20 > The problem is that most drivers in XFree86 don't _want_ to be fbdev comp= liant. > The solution is to convince the hardcode anti-fbdev XFree86 guys to use t= he > fbdev if it's present. Fbdev is part of the kernel API. Circumventing the= API > is bad behavior. The opposition seems to be mostly against the fbdev support being spread over the drivers, which is hard to maintain. If we could move it into an common layer, there should be no problem. I do have the basic idea how to do it but I suspect it would require changes to the driver interface so it might have to wait for XFree86 5.x (provided anyone actually tries :). --=20 Earthling Michel D=E4nzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast |
|
From: James S. <jsi...@tr...> - 2002-05-07 18:03:14
|
> I get the oops below at boot time if "vga=0x0305" is on the command > line. If I take it off, I can boot just fine. Hm. Can you wait a few days. I'm porting the vesa driver to the new api. I will soon release a new driver. |
754 messages has been excluded from this view by a project administrator.
