From: James Simmons <hidden> Date: 2003-10-15 22:59:39
Here is the latest fbdev patches. Please test!!! Many new enhancements.
Several fixes. The patch is against 2.6.0-test7
http://phoenix.infradead.org/~jsimmons/fbdev.diff.gz
bk://fbdev.bkbits.net/fbdev-2.5
Documentation/fb/neofb.txt | 27
MAINTAINERS | 5
drivers/char/vt_ioctl.c | 12
drivers/video/Kconfig | 130
drivers/video/Makefile | 11
drivers/video/acornfb.c | 1
drivers/video/asiliantfb.c | 619
drivers/video/aty/Makefile | 1
drivers/video/aty/aty128fb.c | 1
drivers/video/aty/atyfb.h | 12
drivers/video/aty/atyfb_base.c | 28
drivers/video/aty/mach64_cursor.c | 254
drivers/video/bw2.c | 74
drivers/video/cfbimgblt.c | 2
drivers/video/cg14.c | 98
drivers/video/cg3.c | 79
drivers/video/cg6.c | 89
drivers/video/chipsfb.c | 4
drivers/video/cirrusfb.c | 1
drivers/video/console/Makefile | 29
drivers/video/console/fbcon.c | 574
drivers/video/console/fbcon.h | 3
drivers/video/controlfb.c | 10
drivers/video/cyber2000fb.c | 1
drivers/video/epson1355fb.c | 967 -
drivers/video/fbmem.c | 391
drivers/video/fbmon.c | 10
drivers/video/ffb.c | 110
drivers/video/g364fb.c | 78
drivers/video/i810/Makefile | 7
drivers/video/i810/i810_main.c | 21
drivers/video/igafb.c | 5
drivers/video/imsttfb.c | 7
drivers/video/leo.c | 78
drivers/video/logo/Kconfig | 2
drivers/video/logo/Makefile | 49
drivers/video/logo/logo.c | 10
drivers/video/macfb.c | 34
drivers/video/matrox/matroxfb_base.c | 8
drivers/video/matrox/matroxfb_crtc2.c | 1
drivers/video/modedb.c | 4
drivers/video/neofb.c | 339
drivers/video/p9100.c | 62
drivers/video/platinumfb.c | 10
drivers/video/pm2fb.c | 3010 +---
drivers/video/pvr2fb.c | 846 -
drivers/video/radeonfb.c | 3
drivers/video/riva/fbdev.c | 171
drivers/video/riva/nv_type.h | 12
drivers/video/sa1100fb.c | 1
drivers/video/sgivwfb.c | 12
drivers/video/sis/300vtbl.h | 2455 ---
drivers/video/sis/310vtbl.h | 3515 +----
drivers/video/sis/init.c | 8364 +++++-------
drivers/video/sis/init.h | 2874 +++-
drivers/video/sis/init301.c |21989 +++++++++++++++++-----------------
drivers/video/sis/init301.h | 535
drivers/video/sis/initdef.h | 357
drivers/video/sis/oem300.h | 502
drivers/video/sis/oem310.h | 181
drivers/video/sis/osdef.h | 122
drivers/video/sis/sis_accel.c | 68
drivers/video/sis/sis_accel.h | 27
drivers/video/sis/sis_main.c | 4592 +++----
drivers/video/sis/sis_main.h | 713 -
drivers/video/sis/vgatypes.h | 267
drivers/video/sis/vstruct.h | 218
drivers/video/skeletonfb.c | 74
drivers/video/softcursor.c | 200
drivers/video/sstfb.c | 2
drivers/video/stifb.c | 1
drivers/video/tcx.c | 115
drivers/video/tdfxfb.c | 87
drivers/video/tgafb.c | 177
drivers/video/tridentfb.c | 1
drivers/video/valkyriefb.c | 548
drivers/video/vesafb.c | 17
drivers/video/vgastate.c | 1
include/linux/fb.h | 131
include/linux/linux_logo.h | 4
include/linux/pci_ids.h | 11
include/video/cvisionppc.h | 51
include/video/epson1355.h | 64
include/video/neomagic.h | 261
include/video/sisfb.h | 105
include/video/tdfx.h | 1
86 files changed, 27909 insertions(+), 29034 deletions(-)
through these ChangeSets:
[off-list ref] (03/10/15 1.1363)
[FBDEV SOFT CURSOR] Fixed size bug.
[FBDEV] Increased size for 64 bit platforms.
[off-list ref] (03/10/15 1.1362)
[FBDEV SOFTWARE CURSOR] We always save the maximum are under the cursor. This way we don't have to worry about cursor resizing.
[off-list ref] (03/10/14 1.1361)
[FBDEV] Implemented the first round of saving and restoring the area under the cursor.
[off-list ref] (03/10/14 1.1359)
[FBDEV] Moved kernel header files to be visible only when compiling for the kernel. Userland doesn't need these header files. It also makes shifting from kernel version to kernel version easier.
[off-list ref] (03/10/14 1.1358)
[SIS FBDEV] Compile fix.
[off-list ref] (03/10/13 1.1347.4.2)
[SIS FBDEV] SIS updates. FIxed CRT1 detection.
[off-list ref] (03/10/03 1.1296.43.4)
[SGIVW FBDEV] Fixed 16 bpp color mode.
[off-list ref] (03/09/29 1.1296.28.2)
[FBDEV] Patch fixes get_std_timing. Current code doesn't search the VESA modedb. Instead it exits after the first iteration with mode calculated by calc_mode_timings.
[off-list ref] (03/09/22 1.1267.1.26)
[FBDEV] Better makefile.
[off-list ref] (03/09/22 1.1267.1.25)
pm2fb-2.6.patch
<jsimmons@debian.(none)> (03/09/19 1.1267.40.2)
[TGA FBDEV] Updates to the tga famebuffer. Added color imageblit support. Added using dec logo for TGA fbdev. Color palette fix.
[off-list ref] (03/09/18 1.1267.1.20)
Update driver with the new API
[off-list ref] (03/09/18 1.1267.1.19)
Update sisfb driver:
- merge with driver version version 090903-1 (from Thomas Winischhofer)
- port driver to the new framebuffer_{alloc,release} API
[off-list ref] (03/09/17 1.1267.1.18)
Update sparc framebuffer drivers to the new API.
[off-list ref] (03/09/17 1.1267.33.1)
Add new API framebuffer_alloc and framebuffer_release.
Framebuffer info structure (ie. struct fb_info) must be obtained from
framebuffer_alloc. When it is no longer needed (after unregister_framebuffer
and clean up) it can be released using framebuffer_release.
If the framebuffer is not registered yet (eg. on error path) then fb_info must
be released via kfree.
[off-list ref] (03/09/16 1.1267.1.16)
[MACH 64 FBDEV] Updated to new cursor api.
<jsimmons@debian.(none)> (03/09/14 1.1267.1.14)
[FBDEV} Final cursor api.
[off-list ref] (03/09/04 1.1153.146.5)
[FBDEV] Cleanup for Configuration of Mach64 driver.
[off-list ref] (03/09/04 1.1153.146.4)
[FBDEV] Fixed the cursor code. Also some cleanup with move_buf_*.
[off-list ref] (03/09/04 1.1153.146.3)
[FBDEV] Currcon removal. fbcon.c does this for us.
[off-list ref] (03/09/04 1.1153.146.2)
[FBDEV MODEDB] Better support for 1400x1050 modes.
[off-list ref] (03/08/21 1.1153.1.97)
[FBDEV] Removed currcon from low level drivers.
[off-list ref] (03/08/21 1.1153.1.96)
[FBDEV] Sysfs support.
[off-list ref] (03/08/18 1.1153.6.4)
[RIVA FBDEV] Finally cursor api is complete. A few bugs yet but now to start on other drivers.
[off-list ref] (03/08/15 1.1153.6.2)
[TDFX FBDEV] Fixed Interlace. Only for Banshee interlace wasn't supported.
Added Double scanline mode.
Fixed the foreground color value for tdfxfb_fillrect. For Truecolor modes we have to map the to the proper color value
<jsimmons@bohr.(none)> (03/08/11 1.1123.21.2)
[NEOMAGIC FBDEV] Add going between graphics and VGA text mode.
[off-list ref] (03/07/21 1.1046.416.32)
[TDFX FBDEV] Fixes to make the image blitter work. Also the color handling code was fixed.
[off-list ref] (03/07/15 1.1046.416.28)
[FBCON] Always turn off the cursor in fbcon_cursor. The reason is that cursor might try to blink while we are reprogramming the hardware.
[off-list ref] (03/07/11 1.1046.416.25)
[IMSTT FBDEV] Free up resources when it fails.
[off-list ref] (03/07/11 1.1046.416.24)
[FBDEV] Makefiel cleanups.
[off-list ref] (03/07/11 1.1046.416.23)
[ASILIANT FBDEV] Added support for the asiliant graphics chipset.
[off-list ref] (03/07/09 1.1046.416.18)
[RIVA FBDEV] Support for more versions of GEFORCE 4. Also some cursor cleanup to allow it to compile.
[off-list ref] (03/07/08 1.1046.416.15)
[SIS FBDEV] Updates to the SiS framebuffer driver. Add support for 760 chipset, LCD scaling.
<jsimmons@kozmo.(none)> (03/07/03 1.1046.416.12)
[NEOMAGIC FBDEV] Fixed a nasty bug in the copyarea function. It wasn't testing for the condition when both regions have the same y coordinates but are over lapping. This casued a corrpution of data. Also started ot used the macros in vga.h.
<jsimmons@kozmo.(none)> (03/06/30 1.1046.416.7)
[LOGO] Display the correct logo for MIPS DEC workstations.
<jsimmons@kozmo.(none)> (03/06/25 1.1046.416.1)
[FBCON] Removed the crappy ROP_COPY/ROP_XOR test for flashing the cursor. Now we disable and enable the cursor timer instead.
<jsimmons@kozmo.(none)> (03/06/24 1.1046.1.192)
[FBDEV] Now we can use a specific hardware mapper for different hardware functionality.
<jsimmons@kozmo.(none)> (03/06/23 1.1046.1.188)
[VGA CORE] Added needed vmalloc header.
<jsimmons@kozmo.(none)> (03/06/23 1.1046.1.185)
[FBCON] When using 512 characters, the mouse pointer starts using the wrong complement_mask after a console reset.
<jsimmons@kozmo.(none)> (03/06/23 1.1046.1.184)
[FBDEV] Made chipsfb/controlfb/platinumfb use the xxfb kernel command line string.
[off-list ref] (03/06/18 1.1046.1.180)
[MAC FBDEV] Bug fixes.
[off-list ref] (03/06/15 1.1046.1.176)
[SIS FBDEV] More updates for the SIS driver.
[off-list ref] (03/06/14 1.1046.1.174)
[CONTROL/PLATINUM FBDEV] Fix to match change in fb_set_var.
[off-list ref] (03/06/10 1.1046.1.170)
[FBDEV] Fixed a issue with soft_cursor. It only worked with drivers with a pixmap.scan_align of 1. Now it will work with any.
<jsimmons@kozmo.(none)> (03/06/07 1.1046.1.164)
[SIS FBDEV] Fixed sysnc issue.
<jsimmons@kozmo.(none)> (03/06/05 1.1046.1.160)
[FBCON] Cleared out the struct fb_cursor we passed in. Other wise we get random data being used.
<jsimmons@kozmo.(none)> (03/05/30 1.1046.1.155)
[FBDEV GENERIC ACCEL] Fixed why logo was not displayed for some.
[off-list ref] (03/05/24 1.1046.155.3)
[VALKYRUE FBDEV] Ported to new api.
[off-list ref] (03/05/23 1.1046.155.1)
[FBDEV] Updates to explain the new cursor api.
[off-list ref] (03/05/23 1.1046.1.142)
[EPSON FRAMEBUFFER] Ported to the new api. Added support for the arm platform.
[off-list ref] (03/05/15 1.1046.84.18)
[SIS FBDEV] SIS Framebuffer updates.
- Added preliminary and untested support for SiS660
- Added DDC support
- Enhanced proprietary programming API for compatibility with X driver
and upcoming SDL updates and upcoming vidix driver for mplayer
- Fixes for video bridge output on various HW combinations
- Fixes in TV detection
- Reduced source size by removing duplicated data
- Updated Kconfig descriptions
[off-list ref] (03/05/14 1.1046.73.2)
[PVR2 FBDEV] Port of the Dreamcast Frambuffer to the new api.
[off-list ref] (03/05/12 1.1046.7.19)
[FBCON] set_con2fb_map wasn't testing to see the VC we where mapping to actually exist. Now it does.
I add code to fbcon_cursor to reset the hotspot if it was changed by userland.
[off-list ref] (03/05/12 1.1046.7.17)
[RIVA FBDEV] Removal of exccess variable. Kills off a few warnings.
[off-list ref] (03/05/12 1.1046.7.16)
[VESA FBDEV] Removed the EDID code. The results where mixed. It worked for some but not for others.
[off-list ref] (03/05/12 1.1046.7.15)
[CONSOLE] This patch fixes the problem of not being able to set the fonts on VCs other than the first one. This also was the bug that was casuing dual head (vga and mda) to lock up.
<jsimmons@kozmo.(none)> (03/05/02 1.1042.122.2)
[FBDEV] Synced to kdev_t change.
<jsimmons@kozmo.(none)> (03/04/22 1.1042.37.2)
[FBDEV] Moved pixmap to the kernel side of the header. Will not be needed for ioctl calls at the present time.
[FBCON] Lots more optimizations.
<jsimmons@kozmo.(none)> (03/04/21 1.1042.37.1)
[LOGO] Removed fb_ prefix. Wil be used by other drivers such as the newport driver.
[G354 FBDEV] Now use the final cursor api.
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php
Cool. I've had the below fix floating about for a while. Is it still
relevant?
From: Chris Heath <redacted>
I am still seeing a lot of cursors being left behind. It is not a race
condition or anything -- in the TTY line editor, it happens about 50% of
the time when you press backspace.
What appears to be happening is the cursor is flashing twice as slowly
as the driver thinks it is, so of course it's wrong half the time when
it comes to erase the cursor.
The patch below fixes it for me.
drivers/video/softcursor.c | 6 ++++++
1 files changed, 6 insertions(+)
diff -puN drivers/video/softcursor.c~cursor-flashing-fix drivers/video/softcursor.c
@@ -74,6 +74,12 @@ int soft_cursor(struct fb_info *info, stif(info->cursor.image.data)info->fbops->fb_imageblit(info,&info->cursor.image);++if(!info->cursor.enable){+for(i=0;i<size;i++)+dst[i]^=info->cursor.mask[i];+}+return0;}
_
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php
_
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php
Cool. I've had the below fix floating about for a while. Is it still
relevant?
Its not the proper fix. The latest patch fixes this problem. I had to save
the area under the cursor and redraw that area when the cursor was
disabled or moved. The cursor api is set in stone from the drivers
prespective. So it will be easy for driver writers to make use of
a hardware cursor. The old cursor code was written around a software
emulated cursor. The new code favors hardware cursors with software
emulation the exception.
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php
From: James Simmons <hidden> Date: 2003-10-15 23:27:50
James Simmons [off-list ref] wrote:
quoted
Here is the latest fbdev patches.
This one comes up again and again. What should we do with it?
I applied it. I also have Ben's new driver avaiable for testing.
The diff I released uses Ben's new driver but in BK I'm stilling using teh
old driver.
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php
I'd say drop it, as it's wrong. :) It's like this in Ben's tree:
/* Update fix */
if (accel)
info->fix.line_length = rinfo->pitch*64;
else
info->fix.line_length = mode->xres_virtual * ((mode->bits_per_pixel +
1) / 8);
--
Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer
Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php
From: Jan De Luyck <hidden> Date: 2003-10-16 05:09:14
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Thursday 16 October 2003 00:59, James Simmons wrote:
Here is the latest fbdev patches. Please test!!! Many new enhancements.
Several fixes. The patch is against 2.6.0-test7
Does this fix the problems with the Radeon M9 fbconsole?
Thanks.
Jan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
iD8DBQE/jifrUQQOfidJUwQRAqKJAJ0TZkEIoHkSCOs/x0A5o0WzoUZj3ACffS82
dLURuWclB+Ya7Bm+b5VfPw0=
=j2SQ
-----END PGP SIGNATURE-----
From: Jan De Luyck <hidden> Date: 2003-10-16 05:17:22
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Thursday 16 October 2003 00:59, James Simmons wrote:
Here is the latest fbdev patches. Please test!!! Many new enhancements.
Several fixes. The patch is against 2.6.0-test7
Does this fix the problems with the Radeon M9 fbconsole?
Thanks.
Jan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
iD8DBQE/jinZUQQOfidJUwQRArDzAJ0busbLZYHQFgBUi52lPFWh8/SC2ACfc/gm
GzPY+XcAD3quJpKGsuWJ6vA=
=JoIs
-----END PGP SIGNATURE-----
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2003-10-16 08:20:08
On Thu, 2003-10-16 at 01:20, Andrew Morton wrote:
James Simmons [off-list ref] wrote:
quoted
Here is the latest fbdev patches.
This one comes up again and again. What should we do with it?
The fix is wrong for accelerated displays.
rinfo->pitch should be initialized previously, but then, I'm not sure
what version of radeonfb James actually has in his tree. I'm mostly
rewriting it now, though my "new" version hasn't been submited yet,
it's definitely not ready.
I could eventually submit an updated "old" version though...
Ben.
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php
From: Carlo E. Prelz <hidden> Date: 2003-10-16 09:19:27
Subject: [Linux-fbdev-devel] Re: FBDEV 2.6.0-test7 updates.
Date: gio, ott 16, 2003 at 12:27:44 +0100
Quoting James Simmons (jsimmons@infradead.org):
I applied it. I also have Ben's new driver avaiable for testing.
The diff I released uses Ben's new driver but in BK I'm stilling using teh
old driver.
I am the happy owner of a "Club"-branded Radeon9200 video card. Here
are my experiences using your diff.
My card has a PCI id of 5964. Here you can read the output of 'lspci
-vvv' for it:
--8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<--
01:00.0 VGA compatible controller: ATI Technologies Inc: Unknown device 5964 (rev 01) (prog-if 00 [VGA])
Subsystem: C.P. Technology Co. Ltd: Unknown device 2073
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: 96 (2000ns min), cache line size 08
Interrupt: pin A routed to IRQ 16
Region 0: Memory at c0000000 (32-bit, prefetchable) [size=256M]
Region 1: I/O ports at b800 [size=256]
Region 2: Memory at dfef0000 (32-bit, non-prefetchable) [size=64K]
Expansion ROM at <unassigned> [disabled] [size=128K]
Capabilities: [58] AGP version 3.0
Status: RQ=256 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64- HTrans- 64bit- FW+ AGP3+ Rate=x4,x8
Command: RQ=1 ArqSz=0 Cal=0 SBA+ AGP- GART64- 64bit- FW- Rate=<none>
Capabilities: [50] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
--8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<--
The only 9200 listed in pci_ids.h had an
id of 5960. I added a new line, as follows:
Again, I just blindly duplicated the entry for the other 9200. Now the
stuff compiled, but if I chose to make a radeonfb module, I got a
message stating that
WARNING: /lib/modules/2.6.0-test7/kernel/drivers/video/aty/radeonfb.ko needs unknown symbol release_console_sem
Well, I compiled the fb stuff in kernel. The card was eventually
recognized:
radeonfb_pci_register BEGIN
radeonfb: probed DDR SGRAM 131072k videoram
radeonfb: ref_clk=2700, ref_div=12, xclk=16600 from BIOS
Starting monitor auto detection...
radeonfb: Monitor 1 type CRT found
radeonfb: Monitor 2 type no found
radeonfb: ATI Radeon Yd 9200 RV280 DDR SGRAM 128 MB
radeonfb_pci_register END
(BTW what does "type no" mean? I have a monitor connected to the DVD
plug, as well as my normal LCD monitor on the VGA plug - both monitors
show the framebuffer image)
But, always at 640x480. My adding
video=radeonfb:1280x1024-32@60
to the append line in Lilo did not cause any visible effect. Running
'fbset 1280x1024-60' did indeed change the resolution on my two
monitors (although with wrong number of lines and columns - unpleasant
but I know how to fix that). But if I then changed to another virtual
console, both my monitors went black. The LCD one complained that it
was fed invalid frequencies (103.1 kHz horizontal, 197.8 Hz
vertical). At this point, changing virtual consoles had no effect
anymore, and if I typed Ctrl-Alt-Del, the machine would beep (meaning
it caught the reboot request) but nothing would happen
thereafter. Only a hard reboot would give me back the machine.
(There is also this fancy special effect: the cursor is not
full-white, but with cute fractal-like black pixels inside.)
What can I do to help debugging this code? (I am not bk-enabled!)
Carlo
--
* Se la Strada e la sua Virtu' non fossero state messe da parte,
* K * Carlo E. Prelz - fluido@fluido.as che bisogno ci sarebbe
* di parlare tanto di amore e di rettitudine? (Chuang-Tzu)
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php
From: Sven Luther <hidden> Date: 2003-10-16 09:29:09
On Thu, Oct 16, 2003 at 11:19:18AM +0200, Carlo E. Prelz wrote:
/* Radeon RV280 (9200) */
#define PCI_DEVICE_ID_ATI_RADEON_Y_ 0x5960
+#define PCI_DEVICE_ID_ATI_RADEON_Yz 0x5964
/* Radeon R300 (9500) */
#define PCI_DEVICE_ID_ATI_RADEON_AD 0x4144
/* Radeon R300 (9700) */
(I did not know how to call it. _Yz did not exist, so I grabbed it. Is
there any logic in these codes?)
You use the ascii code of the id :
0x41 -> A, 0x44 -> D thus 0x4144 -> AD.
So, the 0x5964 must be Yd.
Friendly,
Sven Luther
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2003-10-16 10:01:24
On Thu, 2003-10-16 at 11:19, Carlo E. Prelz wrote:
Subject: [Linux-fbdev-devel] Re: FBDEV 2.6.0-test7 updates.
Date: gio, ott 16, 2003 at 12:27:44 +0100
Quoting James Simmons (jsimmons@infradead.org):
quoted
I applied it. I also have Ben's new driver avaiable for testing.
The diff I released uses Ben's new driver but in BK I'm stilling using teh
old driver.
I am the happy owner of a "Club"-branded Radeon9200 video card. Here
are my experiences using your diff.
My card has a PCI id of 5964. Here you can read the output of 'lspci
-vvv' for it:
My new driver (bk://ppc.bkbits.net/linuxppc-2.5-benh) now uses a copy
of XFree PCI IDs list, making it much easier to keep in sync. It should
also support the 9200.
Ben.
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php
From: Carlo E. Prelz <hidden> Date: 2003-10-16 10:19:10
Subject: Re: [Linux-fbdev-devel] Re: FBDEV 2.6.0-test7 updates.
Date: gio, ott 16, 2003 at 12:00:32 +0200
Quoting Benjamin Herrenschmidt (benh@kernel.crashing.org):
My new driver (bk://ppc.bkbits.net/linuxppc-2.5-benh) now uses a copy
of XFree PCI IDs list, making it much easier to keep in sync. It should
also support the 9200.
The latest (*NON*bk) patch distributed by James appears to include your
new driver. The header from radeon_base.c reads:
--8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<--
/*
* drivers/video/radeonfb.c
* framebuffer driver for ATI Radeon chipset video boards
*
* Copyright 2003 Ben. Herrenschmidt [off-list ref]
* Copyright 2000 Ani Joshi [off-list ref]
*
* i2c bits from Luca Tettamanti [off-list ref]
*
* Special thanks to ATI DevRel team for their hardware donations.
*
* ...Insert GPL boilerplate here...
*
* TODO: - Bring a couple of cleanups from 2.4 to the mode setting code,
* - Split CRT vs. FP register calc/setting
* - Add CRTC2 support for mirror at least, dual head then
* - Add back some accel
*
*/
#define RADEON_VERSION "0.2.0"
--8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<--
Thus the rest of my previous message should be referred to
your new driver.
Carlo
PS I am BK-handicapped. I had downloaded the program, and tried your
instruction as per an old message of yours, and no download would take
place. Since, if I recall correctly, bk cannot be used for free on
closed-source projects, I cannot switch to it (nor lose too much time
on it): I work on projects of both types, and changing every time
between RCS/CVS and bk would be very umcomfortable.
--
* Se la Strada e la sua Virtu' non fossero state messe da parte,
* K * Carlo E. Prelz - fluido@fluido.as che bisogno ci sarebbe
* di parlare tanto di amore e di rettitudine? (Chuang-Tzu)
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2003-10-16 10:42:27
On Thu, 2003-10-16 at 12:19, Carlo E. Prelz wrote:
Subject: Re: [Linux-fbdev-devel] Re: FBDEV 2.6.0-test7 updates.
Date: gio, ott 16, 2003 at 12:00:32 +0200
Quoting Benjamin Herrenschmidt (benh@kernel.crashing.org):
quoted
My new driver (bk://ppc.bkbits.net/linuxppc-2.5-benh) now uses a copy
of XFree PCI IDs list, making it much easier to keep in sync. It should
also support the 9200.
The latest (*NON*bk) patch distributed by James appears to include your
new driver. The header from radeon_base.c reads:
I think it's an older version that James included as the current one
has support for the 9200. I'm still updating it very regulary as it's
not considered as "finished" work yet :) Though testing is welcome,
I try to keep it working at any stage.
Ben.
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2003-10-16 10:43:10
PS I am BK-handicapped. I had downloaded the program, and tried your
instruction as per an old message of yours, and no download would take
place. Since, if I recall correctly, bk cannot be used for free on
closed-source projects, I cannot switch to it (nor lose too much time
on it): I work on projects of both types, and changing every time
between RCS/CVS and bk would be very umcomfortable.
You also have an rsync mirror of that tree at
source.mivsta.com::linuxppc-2.5-benh
Ben.
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php
When reaming entries in pci_ids.h you should check whether there are
other users.
The following compile error was caused by your patch:
<-- snip -->
...
CC drivers/char/agp/ati-agp.o
drivers/char/agp/ati-agp.c:421: error: `PCI_DEVICE_ID_ATI_RS300_100'
undeclared here (not in a function)
...
make[3]: *** [drivers/char/agp/ati-agp.o] Error 1
<-- snip ->
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php
From: Carlo E. Prelz <hidden> Date: 2003-10-16 10:50:20
Subject: Re: [Linux-fbdev-devel] Re: FBDEV 2.6.0-test7 updates.
Date: gio, ott 16, 2003 at 12:41:32 +0200
Quoting Benjamin Herrenschmidt (benh@kernel.crashing.org):
I think it's an older version that James included as the current one
has support for the 9200. I'm still updating it very regulary as it's
not considered as "finished" work yet :) Though testing is welcome,
I try to keep it working at any stage.
The version I am using *has* support for the 9200, but only recognizes
a PCI id of 5960, and my card has 5964. Thus I added the PCI id and
the card is eventually recognized as a 9200. Details are in the first
message I sent to the list.
Anyway, I now have to leave. I will try to dedicate some time to this
again tomorrow morning. I will try the rsync access.
Carlo
--
* Se la Strada e la sua Virtu' non fossero state messe da parte,
* K * Carlo E. Prelz - fluido@fluido.as che bisogno ci sarebbe
* di parlare tanto di amore e di rettitudine? (Chuang-Tzu)
When reaming entries in pci_ids.h you should check whether there are
other users.
The following compile error was caused by your patch:
Ug. I turned on all the DRI and APG drivers and well as the fbdev drivers.
Will fix.
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php
Here is the latest fbdev patches. Please test!!! Many new enhancements.
Several fixes. The patch is against 2.6.0-test7
quoted hunk
--- linux-2.6.0-test7/drivers/video/logo/Makefile Wed Oct 15 19:12:21 2003+++ fbdev-2.6/drivers/video/logo/Makefile Wed Oct 15 19:20:50 2003
@@ -13,30 +13,36 @@obj-$(CONFIG_LOGO_SUPERH_VGA16)+=logo_superh_vga16.oobj-$(CONFIG_LOGO_SUPERH_CLUT224)+=logo_superh_clut224.o-# Dependencies on generated files need to be listed explicitly--$(obj)/%_mono.o:$(src)/%_mono.c--$(obj)/%_vga16.o:$(src)/%_vga16.c--$(obj)/%_clut224.o:$(src)/%_clut224.c--$(obj)/%_gray256.o:$(src)/%_gray256.c--# How to generate them+# mono logo's+$(obj)/logo_linux_mono.o:$(obj)/logo_linux_mono.c+$(obj)/logo_superh_mono.o:$(obj)/logo_superh_mono.c++# vga16 logo's+$(obj)/logo_linux_vga16.o:$(obj)/logo_linux_vga16.c+$(obj)/logo_superh_vga16.o:$(obj)/logo_superh_vga16.c++# clut224 logo's+$(obj)/logo_linux_clut224.o:$(obj)/logo_linux_clut224.c+$(obj)/logo_dec_clut224.o:$(obj)/logo_dec_clut224.c+$(obj)/logo_mac_clut224.o:$(obj)/logo_mac_clut224.c+$(obj)/logo_sgi_clut224.o:$(obj)/logo_sgi_clut224.c+$(obj)/logo_sun_clut224.o:$(obj)/logo_sun_clut224.c+$(obj)/logo_superh_clut224.o:$(obj)/logo_superh_clut224.c
Why did you replace the generic rules?
quoted hunk
--- linux-2.6.0-test7/drivers/video/radeonfb.c Wed Oct 15 19:12:22 2003+++ fbdev-2.6/drivers/video/radeonfb.c Wed Oct 15 19:20:51 2003
drivers/video/radeonfb.c still exists, while the build system now uses the one
in drivers/video/aty?
quoted hunk
--- linux-2.6.0-test7/drivers/video/sgivwfb.c Wed Oct 15 19:12:22 2003+++ fbdev-2.6/drivers/video/sgivwfb.c Wed Oct 15 19:20:51 2003
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
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
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php
From: Sam Ravnborg <hidden> Date: 2003-10-16 20:40:26
On Thu, Oct 16, 2003 at 09:58:44PM +0200, Geert Uytterhoeven wrote:
quoted
--- linux-2.6.0-test7/drivers/video/logo/Makefile Wed Oct 15 19:12:21 2003+++ fbdev-2.6/drivers/video/logo/Makefile Wed Oct 15 19:20:50 2003
@@ -13,30 +13,36 @@obj-$(CONFIG_LOGO_SUPERH_VGA16)+=logo_superh_vga16.oobj-$(CONFIG_LOGO_SUPERH_CLUT224)+=logo_superh_clut224.o-# Dependencies on generated files need to be listed explicitly--$(obj)/%_mono.o:$(src)/%_mono.c--$(obj)/%_vga16.o:$(src)/%_vga16.c--$(obj)/%_clut224.o:$(src)/%_clut224.c--$(obj)/%_gray256.o:$(src)/%_gray256.c--# How to generate them+# mono logo's+$(obj)/logo_linux_mono.o:$(obj)/logo_linux_mono.c+$(obj)/logo_superh_mono.o:$(obj)/logo_superh_mono.c++# vga16 logo's+$(obj)/logo_linux_vga16.o:$(obj)/logo_linux_vga16.c+$(obj)/logo_superh_vga16.o:$(obj)/logo_superh_vga16.c++# clut224 logo's+$(obj)/logo_linux_clut224.o:$(obj)/logo_linux_clut224.c+$(obj)/logo_dec_clut224.o:$(obj)/logo_dec_clut224.c+$(obj)/logo_mac_clut224.o:$(obj)/logo_mac_clut224.c+$(obj)/logo_sgi_clut224.o:$(obj)/logo_sgi_clut224.c+$(obj)/logo_sun_clut224.o:$(obj)/logo_sun_clut224.c+$(obj)/logo_superh_clut224.o:$(obj)/logo_superh_clut224.c
Why did you replace the generic rules?
I made that a few months ago - I do not remember the details.
But in order to use a common rule for all logos I had to list them
explicit one by one.
I also recall that the old makefile used some built-in rules to create
the logo files - and the above may have been required to avoid that
as well.
Sam
From: Otto Solares <hidden> Date: 2003-10-16 21:08:37
On Thu, Oct 16, 2003 at 12:00:32PM +0200, Benjamin Herrenschmidt wrote:
On Thu, 2003-10-16 at 11:19, Carlo E. Prelz wrote:
quoted
Subject: [Linux-fbdev-devel] Re: FBDEV 2.6.0-test7 updates.
Date: gio, ott 16, 2003 at 12:27:44 +0100
Quoting James Simmons (jsimmons@infradead.org):
quoted
I applied it. I also have Ben's new driver avaiable for testing.
The diff I released uses Ben's new driver but in BK I'm stilling using teh
old driver.
I am the happy owner of a "Club"-branded Radeon9200 video card. Here
are my experiences using your diff.
My card has a PCI id of 5964. Here you can read the output of 'lspci
-vvv' for it:
My new driver (bk://ppc.bkbits.net/linuxppc-2.5-benh) now uses a copy
of XFree PCI IDs list, making it much easier to keep in sync. It should
also support the 9200.
I think your driver is an improvement over the old one, but:
- Could I2C be ported to kernel I2C api and separated?, so it use would not
require the fbdev module loaded.
- PCI IDs list should be in pci_ids.h as every other drivers, reality is
that adding new IDs to pci_ids.h is not hard so your driver will not be the
exception to the rule.
-solca
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php
From: Carlo E. Prelz <hidden> Date: 2003-10-17 10:04:21
Subject: Re: [Linux-fbdev-devel] Re: FBDEV 2.6.0-test7 updates.
Date: gio, ott 16, 2003 at 12:42:15 +0200
Quoting Benjamin Herrenschmidt (benh@kernel.crashing.org):
You also have an rsync mirror of that tree at
source.mivsta.com::linuxppc-2.5-benh
Ok. I got the code (it is mvista, not mivsta...). My card is
recognized without modifications:
--8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<--
bus pci: add driver radeonfb
radeonfb_pci_register BEGIN
radeonfb: probed DDR SGRAM 131072k videoram
radeonfb: Found Intel x86 BIOS ROM Image
radeonfb: Retreived PLL infos from BIOS
radeonfb: Reference=27.00 MHz (RefDiv=12) Memory=200.00 Mhz, System=166.00 MHz
Starting monitor auto detection...
radeonfb: I2C (port 2) ... not found
radeonfb: I2C (port 4) ... not found
radeonfb: I2C (port 3) ... found CRT display
radeonfb: Monitor 1 type CRT found
radeonfb: EDID probed
========================================
Display Information (EDID)
========================================
EDID Version 1.3
Manufacturer: MED Model: 4720 Serial#: 0
Year: 2001 Week 44
Display Characteristics:
Analog Display Input: Input Voltage - 0.700V/0.300V
Sync: Serration on
Max H-size in cm: 34
Max V-size in cm: 27
Gamma: 2.20
DPMS: Active yes, Suspend yes, Standby yes
RGB Color Display
Chromaticity: RedX: 0.625 RedY: 0.340
GreenX: 0.280 GreenY: 0.595
BlueX: 0.155 BlueY: 0.070
WhiteX: 0.281 WhiteY: 0.311
Default color format is primary
First DETAILED Timing is preferred
Display is GTF capable
Standard Timings
1280x1024@60Hz
Supported VESA Modes
720x400@70Hz
640x480@60Hz
640x480@67Hz
640x480@72Hz
640x480@75Hz
800x600@56Hz
800x600@60Hz
800x600@72Hz
800x600@75Hz
832x624@75Hz
1024x768@60Hz
1024x768@70Hz
1024x768@75Hz
1280x1024@75Hz
1152x870@75Hz
Manufacturer's mask: 0
Detailed Monitor Information
135 MHz 1280 1296 1440 1688 1024 1025 1028 1066 +HSync +VSync
Serial No : 0
Monitor Name : MD 9463 AE
HorizSync : 24-80 KHz
VertRefresh : 56-75 Hz
Max Pixelclock: 130 MHz
========================================
radeonfb: Monitor 2 type no found
radeonfb: ATI Radeon Yd DDR SGRAM 128 MB
radeonfb_pci_register END
bound device '0000:01:00.0' to driver 'radeonfb'
--8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<--
and then
--8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<--
hStart = 664, hEnd = 760, hTotal = 800
vStart = 491, vEnd = 493, vTotal = 525
h_total_disp = 0x4f0063 hsync_strt_wid = 0x8c02a2
v_total_disp = 0x1df020c vsync_strt_wid = 0x8201ea
pixclock = 39721
freq = 2517
post div = 0x8
fb_div = 0x59
ppll_div_3 = 0x30059
lvds_gen_cntl: 08000008
Console: switching to colour frame buffer device 80x30
--8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<--
Then, when changing to 1280x1024, with command
/usr/sbin/fbset -depth 32 1280x1024-60
the actual console changes correctly, but when switching to other VCs,
the monitor again complains saying it gets bad frequencies: 103.1 kHz
horizontal and 197.8 Hz vertical.
If I blindly login, and run the appropriate fbset command, the
terminal works OK. I made this small script:
#!/bin/sh
stty cols 160 rows 64
/usr/sbin/fbset -depth 32 1280x1024-60
consolechars -m iso15 -f iso15graf-16
and gave it a very short name. This way, once the terminal is set, I
can see what I type. I still have to logout and login again because
bash does not change its idea of the number of columns with
stty... So, quite uncomfortable but working ok.
Obviously, if I were able to set the default mode to 1280x1024, things
would be sunny.
video=radeonfb:1280x1024-32@60
and
video=radeonfb:mode:1280x1024-32@60
seems not to produce any visible effect. What is the current proper
way to initialize radeonfb from LILO?
And on a similar topic, could you write a couple of examples about how
to use the parameters included in radeon_base.c? I am thinking
especially of the "mirror" and "monitor_layout" parameters, that I
believe would allow me to use the two or three video outputs of the
card independently. I currently read
0 ATI Radeon Yd
in /proc/fb. I should read two or three lines there, I believe...
Carlo
--
* Se la Strada e la sua Virtu' non fossero state messe da parte,
* K * Carlo E. Prelz - fluido@fluido.as che bisogno ci sarebbe
* di parlare tanto di amore e di rettitudine? (Chuang-Tzu)
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2003-10-17 10:31:40
- Could I2C be ported to kernel I2C api and separated?, so it use would not
require the fbdev module loaded.
I don't plan to do that. The i2c _IS_ using the kernel i2c APIs, but
the proper DDC probing requires various other register tweaking and
I just don't want to have a separate driver tapping the radeon registers
at this point.
I'm really very much in favor of having the fbdev be the kernel API
to display devices in general, including for things like EDID retreival.
- PCI IDs list should be in pci_ids.h as every other drivers, reality is
that adding new IDs to pci_ids.h is not hard so your driver will not be the
exception to the rule.
Looks like you didn't have to deal with all of the merge conflicts
that happen systematically when you have to maintain a kernel tree and
have changes to pci_ids :)
pci_ids.h is hell to manage. Really. And it makes it a lot simpler for now,
at least until the driver is considered as final enough to be merged upstream,
to just keep a copy of the XFree IDs in there. I may do differently once the
driver is complete enough, but not at this point. And no, I'm far from beeing
the only one to decide not to use pci_ids.h :) I try to use it most of the time,
but in the case of radeonfb, it just makes things too painful for now.
Ben.
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2003-10-17 10:50:35
Ok. I got the code (it is mvista, not mivsta...). My card is
recognized without modifications:
Good.
Then, when changing to 1280x1024, with command
/usr/sbin/fbset -depth 32 1280x1024-60
the actual console changes correctly, but when switching to other VCs,
the monitor again complains saying it gets bad frequencies: 103.1 kHz
horizontal and 197.8 Hz vertical.
Not sure what's up here. The driver is quite passive regarding
the mode for other VCs, it sort of expect the fbcon layer do pick up
the default mode and use it for other consoles. I'm not sure what's
wrong here.
In a more general way, I really lack the ability to change the console
size with fbset like I could do with 2.4. I don't know if James revived
that feature in his latest patches though. The stty thing isn't very
reliable imho. Especially on monitors that don't like the standard
modedb.
And on a similar topic, could you write a couple of examples about how
to use the parameters included in radeon_base.c? I am thinking
especially of the "mirror" and "monitor_layout" parameters, that I
believe would allow me to use the two or three video outputs of the
card independently. I currently read
I have to see what I'll do of these parameters first. For now, the
driver only really use the first head. I haven't yet implemented support
for the second one, though it's on my list of things to do.
0 ATI Radeon Yd
in /proc/fb. I should read two or three lines there, I believe...
From: Carlo E. Prelz <hidden> Date: 2003-10-17 11:10:38
Subject: Re: [Linux-fbdev-devel] Re: FBDEV 2.6.0-test7 updates.
Date: ven, ott 17, 2003 at 12:49:38 +0200
Quoting Benjamin Herrenschmidt (benh@kernel.crashing.org):
Not sure what's up here. The driver is quite passive regarding
the mode for other VCs, it sort of expect the fbcon layer do pick up
the default mode and use it for other consoles. I'm not sure what's
wrong here.
In a more general way, I really lack the ability to change the console
size with fbset like I could do with 2.4. I don't know if James revived
that feature in his latest patches though. The stty thing isn't very
reliable imho. Especially on monitors that don't like the standard
modedb.
fbset really does a great mess, if mixed up with stty. It took me
almost an hour to find the right combination. Now, I have a stable
system, apart from the fact of having to do blind termnal setup for
each VC...
quoted
And on a similar topic, could you write a couple of examples about how
to use the parameters included in radeon_base.c? I am thinking
especially of the "mirror" and "monitor_layout" parameters, that I
believe would allow me to use the two or three video outputs of the
card independently. I currently read
I have to see what I'll do of these parameters first. For now, the
driver only really use the first head. I haven't yet implemented support
for the second one, though it's on my list of things to do.
Aha... So, from what you know, is there any possibility (fb, X, X with
ATI drivers, anything else) to use the video output (or the second
head) of radeon cards under Linux? And have you tried your drivers
with 2 cards (one PCI and one AGP)?
And in all cases, why is parameter "mode" not working? If I could set
1280x1024-32@60 from Lilo, most of my problems would be solved...
Carlo
--
* Se la Strada e la sua Virtu' non fossero state messe da parte,
* K * Carlo E. Prelz - fluido@fluido.as che bisogno ci sarebbe
* di parlare tanto di amore e di rettitudine? (Chuang-Tzu)
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2003-10-17 11:17:34
Aha... So, from what you know, is there any possibility (fb, X, X with
ATI drivers, anything else) to use the video output (or the second
head) of radeon cards under Linux? And have you tried your drivers
with 2 cards (one PCI and one AGP)?
I haven't tried with 2 cards, no. It's possible to do dual head
with XFree.
And in all cases, why is parameter "mode" not working? If I could set
1280x1024-32@60 from Lilo, most of my problems would be solved...
I'll check that out. The new module parameter thing isn't that good,
I think I'll revive the old stuff for a while.
Ben.
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2003-10-17 11:19:41
quoted
--- linux-2.6.0-test7/drivers/video/radeonfb.c Wed Oct 15 19:12:22 2003+++ fbdev-2.6/drivers/video/radeonfb.c Wed Oct 15 19:20:51 2003
drivers/video/radeonfb.c still exists, while the build system now uses the one
in drivers/video/aty?
I haven't checked what James did here. In my tree, I was careful to keep
both old and new drivers available via 2 separate CONFIG options.
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php
Il Fri, Oct 17, 2003 at 12:04:12PM +0200, Carlo E. Prelz ha scritto:
Then, when changing to 1280x1024, with command
/usr/sbin/fbset -depth 32 1280x1024-60
fbset doesn't work with linux 2.6.
Obviously, if I were able to set the default mode to 1280x1024, things
would be sunny.
video=radeonfb:1280x1024-32@60
and
video=radeonfb:mode:1280x1024-32@60
seems not to produce any visible effect. What is the current proper
way to initialize radeonfb from LILO?
video=radeonfb radeonfb.mode_option=1280x1024-32@60
Luca
--
Reply-To: kronos@kronoz.cjb.net
Home: http://kronoz.cjb.net
You and me baby ain't nothin' but mammals
So let's do it like they do on the Discovery Channel
Il Fri, Oct 17, 2003 at 01:16:37PM +0200, Benjamin Herrenschmidt ha scritto:
quoted
Aha... So, from what you know, is there any possibility (fb, X, X with
ATI drivers, anything else) to use the video output (or the second
head) of radeon cards under Linux? And have you tried your drivers
with 2 cards (one PCI and one AGP)?
I haven't tried with 2 cards, no. It's possible to do dual head
with XFree.
quoted
And in all cases, why is parameter "mode" not working? If I could set
1280x1024-32@60 from Lilo, most of my problems would be solved...
I'll check that out. The new module parameter thing isn't that good,
I think I'll revive the old stuff for a while.
The following patch restores the setup function so that radeonfb can be
given options like other fb drivers. There's also a small typo fix
(force_dfp -> panel_yres).
===== drivers/video/fbmem.c 1.71 vs edited =====
--- 1.71/drivers/video/fbmem.c Sun Sep 7 23:07:57 2003+++ edited/drivers/video/fbmem.c Fri Oct 17 16:37:55 2003
@@ -2405,6 +2439,6 @@MODULE_PARM_DESC(nomtrr,"bool: disable use of MTRR registers");#endifmodule_param(panel_yres,int,0);-MODULE_PARM_DESC(force_dfp,"int: set panel yres");+MODULE_PARM_DESC(panel_yres,"int: set panel yres");module_param(mode_option,charp,0);MODULE_PARM_DESC(mode_option,"Specify resolution as \"<xres>x<yres>[-<bpp>][@<refresh>]\" ");
Luca
--
Reply-To: kronos@kronoz.cjb.net
Home: http://kronoz.cjb.net
I went to God just to see
And I was looking at me
Saw heaven and hell were lies
When I'm God everyone dies
From: James Simmons <hidden> Date: 2003-10-17 16:45:35
rinfo->pitch should be initialized previously, but then, I'm not sure
what version of radeonfb James actually has in his tree. I'm mostly
rewriting it now, though my "new" version hasn't been submited yet,
it's definitely not ready.
Both the old driver and the new driver.
I could eventually submit an updated "old" version though...
From: James Simmons <hidden> Date: 2003-10-17 16:48:09
On Thu, Oct 16, 2003 at 11:19:18AM +0200, Carlo E. Prelz wrote:
quoted
/* Radeon RV280 (9200) */
#define PCI_DEVICE_ID_ATI_RADEON_Y_ 0x5960
+#define PCI_DEVICE_ID_ATI_RADEON_Yz 0x5964
/* Radeon R300 (9500) */
#define PCI_DEVICE_ID_ATI_RADEON_AD 0x4144
/* Radeon R300 (9700) */
(I did not know how to call it. _Yz did not exist, so I grabbed it. Is
there any logic in these codes?)
You use the ascii code of the id :
0x41 -> A, 0x44 -> D thus 0x4144 -> AD.
So, the 0x5964 must be Yd.
So that is the logic to it?
-------------------------------------------------------
This SF.net email sponsored by: Enterprise Linux Forum Conference & Expo
The Event For Linux Datacenter Solutions & Strategies in The Enterprise
Linux in the Boardroom; in the Front Office; & in the Server Room
http://www.enterpriselinuxforum.com
From: James Simmons <hidden> Date: 2003-10-17 16:52:41
- Could I2C be ported to kernel I2C api and separated?, so it use would not
require the fbdev module loaded.
I don't think that can be done. At least not easily.
- PCI IDs list should be in pci_ids.h as every other drivers, reality is
that adding new IDs to pci_ids.h is not hard so your driver will not be the
exception to the rule.
I agree here. We do need to watch out for the AGP drivers. Changing PCI
Id's can break them. I dicovered that recently.
-------------------------------------------------------
This SF.net email sponsored by: Enterprise Linux Forum Conference & Expo
The Event For Linux Datacenter Solutions & Strategies in The Enterprise
Linux in the Boardroom; in the Front Office; & in the Server Room
http://www.enterpriselinuxforum.com
From: James Simmons <hidden> Date: 2003-10-17 17:29:41
The following patch restores the setup function so that radeonfb can be
given options like other fb drivers. There's also a small typo fix
(force_dfp -> panel_yres).
Applied
-------------------------------------------------------
This SF.net email sponsored by: Enterprise Linux Forum Conference & Expo
The Event For Linux Datacenter Solutions & Strategies in The Enterprise
Linux in the Boardroom; in the Front Office; & in the Server Room
http://www.enterpriselinuxforum.com
From: James Simmons <hidden> Date: 2003-10-17 17:40:52
Not sure what's up here. The driver is quite passive regarding
the mode for other VCs, it sort of expect the fbcon layer do pick up
the default mode and use it for other consoles. I'm not sure what's
wrong here.
Using ssty or fbset only changes the resolution on the local VC. I did
this because often with fbset the user sets the mode to something the
monitor has a hard time with. If this happened to all the VCs then you
have to type blind to fix all the VCs. So IMO it is better to risk losing
one VC then all of them. You can change the size of all VCs by calling the
vt ioctl call VT_RESIZE
In a more general way, I really lack the ability to change the console
size with fbset like I could do with 2.4. I don't know if James revived
that feature in his latest patches though. The stty thing isn't very
reliable imho. Especially on monitors that don't like the standard
modedb.
Not in this set of patches but with client support coming soon we will be
able to change the VCs resolution via fbset again.
-------------------------------------------------------
This SF.net email sponsored by: Enterprise Linux Forum Conference & Expo
The Event For Linux Datacenter Solutions & Strategies in The Enterprise
Linux in the Boardroom; in the Front Office; & in the Server Room
http://www.enterpriselinuxforum.com
On Fri, 2003-10-17 at 10:25, James Simmons wrote:
[...]
The BK tree doesn't have the new radeon driver. I placed the new radeon
driver into the patch so people coudl test it.
I have a Radeon All-In-Wonder 7500. I downloaded the tar.gz patch and
applied it to -test7. The resulting kernel panics at startup, while
test7 with the same config works fine for me.
Before it panics, the penguin shows up at least, so it works a little
bit :-/
I have not had time to attach a serial console to capture the oops yet,
but hope to do that by the end of the day...
--
Torrey Hoffman [off-list ref]
-------------------------------------------------------
This SF.net email sponsored by: Enterprise Linux Forum Conference & Expo
The Event For Linux Datacenter Solutions & Strategies in The Enterprise
Linux in the Boardroom; in the Front Office; & in the Server Room
http://www.enterpriselinuxforum.com
From: Jon Smirl <hidden> Date: 2003-10-17 19:34:52
The people writing the AGP driver have added their ID's in the wrong format.
ATI wants the IDs in the two letter form, not family/chip. The fbdev patch has
the ID's in correct form. The AGP driver should be the one that gets changed.
--- James Simmons <jsimmons@infradead.org> wrote:
quoted
- Could I2C be ported to kernel I2C api and separated?, so it use would not
require the fbdev module loaded.
I don't think that can be done. At least not easily.
quoted
- PCI IDs list should be in pci_ids.h as every other drivers, reality is
that adding new IDs to pci_ids.h is not hard so your driver will not be the
exception to the rule.
I agree here. We do need to watch out for the AGP drivers. Changing PCI
Id's can break them. I dicovered that recently.
-------------------------------------------------------
This SF.net email sponsored by: Enterprise Linux Forum Conference & Expo
The Event For Linux Datacenter Solutions & Strategies in The Enterprise
Linux in the Boardroom; in the Front Office; & in the Server Room
http://www.enterpriselinuxforum.com
_______________________________________________
Linux-fbdev-devel mailing list
Linux-fbdev-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel
=====
Jon Smirl
jonsmirl@yahoo.com
__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com
From: Dave Jones <hidden> Date: 2003-10-17 19:52:05
On Fri, Oct 17, 2003 at 12:34:47PM -0700, Jon Smirl wrote:
> The people writing the AGP driver have added their ID's in the wrong format.
> ATI wants the IDs in the two letter form, not family/chip. The fbdev patch has
> the ID's in correct form. The AGP driver should be the one that gets changed.
The ATI AGPGART driver _always_ used the format it currently does.
Since day 1, when it was written _by ATI engineers_
Your "ATI wants the IDs in two letter form" differs depending on which
ATI engineer you talk to it seems.
Personally, as agpgart maintainer, I couldn't care less what the defines
end up being, as long as it still compiles afterwards.
Dave
--
Dave Jones http://www.codemonkey.org.uk
-------------------------------------------------------
This SF.net email sponsored by: Enterprise Linux Forum Conference & Expo
The Event For Linux Datacenter Solutions & Strategies in The Enterprise
Linux in the Boardroom; in the Front Office; & in the Server Room
http://www.enterpriselinuxforum.com
From: Jon Smirl <hidden> Date: 2003-10-17 22:48:58
--- "Carlo E. Prelz" <fluido@fluido.as> wrote:
(I did not know how to call it. _Yz did not exist, so I grabbed it. Is
there any logic in these codes?)
5964 = 59 hex 64 hex
Convert the PCI ID to ASCII chars
0x59 = Y
0x64 = d
Yd is the right code.
--- "Carlo E. Prelz" <fluido@fluido.as> wrote:
quoted hunk
Subject: [Linux-fbdev-devel] Re: FBDEV 2.6.0-test7 updates.
Date: gio, ott 16, 2003 at 12:27:44 +0100
Quoting James Simmons (jsimmons@infradead.org):
quoted
I applied it. I also have Ben's new driver avaiable for testing.
The diff I released uses Ben's new driver but in BK I'm stilling using teh
old driver.
I am the happy owner of a "Club"-branded Radeon9200 video card. Here
are my experiences using your diff.
My card has a PCI id of 5964. Here you can read the output of 'lspci
-vvv' for it:
--8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<--
01:00.0 VGA compatible controller: ATI Technologies Inc: Unknown device 5964
(rev 01) (prog-if 00 [VGA])
Subsystem: C.P. Technology Co. Ltd: Unknown device 2073
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: 96 (2000ns min), cache line size 08
Interrupt: pin A routed to IRQ 16
Region 0: Memory at c0000000 (32-bit, prefetchable) [size=256M]
Region 1: I/O ports at b800 [size=256]
Region 2: Memory at dfef0000 (32-bit, non-prefetchable) [size=64K]
Expansion ROM at <unassigned> [disabled] [size=128K]
Capabilities: [58] AGP version 3.0
Status: RQ=256 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64-
HTrans- 64bit- FW+ AGP3+ Rate=x4,x8
Command: RQ=1 ArqSz=0 Cal=0 SBA+ AGP- GART64- 64bit- FW-
Rate=<none>
Capabilities: [50] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
--8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<--
The only 9200 listed in pci_ids.h had an
id of 5960. I added a new line, as follows:
PCI_ANY_ID, 0, 0, RADEON_RS300},
{ PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_RADEON_X7, PCI_ANY_ID,
PCI_ANY_ID, 0, 0, RADEON_RS300},
{ PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_RADEON_Y_, PCI_ANY_ID,
PCI_ANY_ID, 0, 0, RADEON_RV280},
+ { PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_RADEON_Yz, PCI_ANY_ID,
PCI_ANY_ID, 0, 0, RADEON_RV280},
{ 0, }
};
MODULE_DEVICE_TABLE(pci, radeonfb_pci_table);
Again, I just blindly duplicated the entry for the other 9200. Now the
stuff compiled, but if I chose to make a radeonfb module, I got a
message stating that
WARNING: /lib/modules/2.6.0-test7/kernel/drivers/video/aty/radeonfb.ko needs
unknown symbol release_console_sem
Well, I compiled the fb stuff in kernel. The card was eventually
recognized:
radeonfb_pci_register BEGIN
radeonfb: probed DDR SGRAM 131072k videoram
radeonfb: ref_clk=2700, ref_div=12, xclk=16600 from BIOS
Starting monitor auto detection...
radeonfb: Monitor 1 type CRT found
radeonfb: Monitor 2 type no found
radeonfb: ATI Radeon Yd 9200 RV280 DDR SGRAM 128 MB
radeonfb_pci_register END
(BTW what does "type no" mean? I have a monitor connected to the DVD
plug, as well as my normal LCD monitor on the VGA plug - both monitors
show the framebuffer image)
But, always at 640x480. My adding
video=radeonfb:1280x1024-32@60
to the append line in Lilo did not cause any visible effect. Running
'fbset 1280x1024-60' did indeed change the resolution on my two
monitors (although with wrong number of lines and columns - unpleasant
but I know how to fix that). But if I then changed to another virtual
console, both my monitors went black. The LCD one complained that it
was fed invalid frequencies (103.1 kHz horizontal, 197.8 Hz
vertical). At this point, changing virtual consoles had no effect
anymore, and if I typed Ctrl-Alt-Del, the machine would beep (meaning
it caught the reboot request) but nothing would happen
thereafter. Only a hard reboot would give me back the machine.
(There is also this fancy special effect: the cursor is not
full-white, but with cute fractal-like black pixels inside.)
What can I do to help debugging this code? (I am not bk-enabled!)
Carlo
--
* Se la Strada e la sua Virtu' non fossero state messe da parte,
* K * Carlo E. Prelz - fluido@fluido.as che bisogno ci sarebbe
* di parlare tanto di amore e di rettitudine? (Chuang-Tzu)
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php
_______________________________________________
Linux-fbdev-devel mailing list
Linux-fbdev-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel
=====
Jon Smirl
jonsmirl@yahoo.com
__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com
-------------------------------------------------------
This SF.net email sponsored by: Enterprise Linux Forum Conference & Expo
The Event For Linux Datacenter Solutions & Strategies in The Enterprise
Linux in the Boardroom; in the Front Office; & in the Server Room
http://www.enterpriselinuxforum.com
From: Pavel Machek <hidden> Date: 2003-10-18 21:28:55
Hi!
I tried those updates (over -test8, I downloaded .gz-version, and it
contained lots of files like include/asm/*, no problems patching,
through). Well, cursor problems only got worse.
VGA-softcursor problems are still there (backspace leaves ghost
cursors behind).
Cursor problems got *worse*. With vanilla, cursor got corrupted when
using gpm. Now it is *allways* corrupted :-(. I'm using vesafb.
Pavel
--
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]