[Dri-devel] Re: [Linux-fbdev-devel] Redesign of kernel graphics interface
On Fri, 7 May 2004, Nicolas Souchu wrote:
On Thu, May 06, 2004 at 02:42:14PM -0700, Jon Smirl wrote:
BenH and others have made proposals for pushing the mode setting code into a
user space library in order to reduce kernel footprint and ease debugging. Most
of the code needed for this library already exists in the current Linux FB
drivers. I'm not sure if this could be relicensed BSD when it is moved to user
space.
One advantage of true graphic drivers (opposed to VESA or more generally bios modes)
is that they can boot some archs in graphic mode (no text mode) without bios.
Exactly what linuxfb was originaly designed to. How do you perform this from
userspace?
Note that this is `early userspace', in initramfs. Graphics would be
initialized a bit later than today, but (hopefully) still sufficiently early.
Even right now fbcon is initialized later than vgacon, because we need bus
probing before we can detect graphics cards.
If you really need kernel messages earlier, you have to fallback to vgacon
(ugh), a serial console, or an early boot console (like PPC BTEXT).
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
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 Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson Lucent use to
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Linux-fbdev-devel] Redesign of kernel graphics interface
On Thu, 6 May 2004, Jon Smirl wrote:
6) What about low memory embedded systems? mesa has an excellent implementation
of OpenGL-ES available for free. http://www.khronos.org/opengles/ It already
supports running out of a dumb framebuffer. OpenGL-ES is small enough that
Qualcomm is putting it into phones. Of course you can always ignore the GUI
standard and do what you want in an embedded system.
What about performance on older systems? Current new embedded CE may be much
faster than an average PC from a few years ago.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
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 Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson Lucent use to
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64-0-0-7 branch and VBE TVOut. Patch included.
I finally got to look at this patch, the patch puts the options in atioption.c in a different order than in atioption.h this stops tv out from working properly with the previous patch, there is an updated patch at http://freedesktop.org/~airlied/mach64-tvout-070504.diff it still doesn't look great on my TV :-( NTSC or PAL, NTSC suffers from shorter scan lines at the top than at the bottom, PAL suffers from a dodgy shake .. makes your eyes hurt ... Dave. On Sun, 28 Mar 2004, Mike Mestnik wrote: He did respond you should be able to find his comments on the user list. IIRC He said that xv != tvout and that xv was in 0-0-7 and this seams to be the case. I think there is some dependant code missing from the tvout patch that also needs to be brought over. I used /linux/tvout-patches/mach64-tvout-20030328.diff.gz for making my patch. Maby the XV patch will have the missing code we need? --- Anish Mistry [EMAIL PROTECTED] wrote: On Saturday 27 March 2004 09:55 pm, you wrote: I'm glad too see it has worked for you. I have had problems with my patch, may I ask how you use it and what you do to make it work? What I did was use atitvout while in X and this worked but only if I didn't do any mode changes or VT switches. Withought the patch atitvout bails saying it can do VBE calles. I think you misread my message. I was NOT able to get it working. I don't use atitvout since there is only the source code available and not a binary which I would be able to run under the Linux ABI. I'm going to try to hand patch Leif's original 4.3 patch later this week to see if I can get it to work. Have you tried to email Leif I did last week, but got no response. --- Anish Mistry [EMAIL PROTECTED] wrote: On Tuesday 23 March 2004 05:16 am, Mike Mestnik wrote: This is nothing more than a HUNK fixed copy of the TVOut patch found on leif's linux page. With this patch the TVOut and other related options are evaluated and it is posible to use atitvout while in X. However I notesed some problems with this patch that only a reboot would fix. There was coruption of 2d texture offsets making the FB filled with odd things from display memory. Something like the GDM login name prompt came in clearly while the rest of the screen was messed up. I'l see if I can't get some screenshots of this. I was unable to get tvout working with your attached patch. Using the 4.3 binaries from Leif's site works fine, but no dri. I'm using FreeBSD. -- Anish Mistry -- Anish Mistry ATTACHMENT part 2 application/pgp-signature __ Do you Yahoo!? Yahoo! Finance Tax Center - File online. File on time. http://taxes.yahoo.com/filing.html --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] S3 twister K gamma correction
Hi, I am using savage driver from savage-2 cvs but it seems the switch Gamma x y z in XF86Config Monitor section doesn't make anything. In Xfree log, we can see parameters are used, but visually there is no difference between gamma 1.0 1.0 1.0 and gamma 0.5 0.5 0.5 Thib. --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] S3 twister K gamma correction
Update to the latest driver (dri trunk) based on tim's code. As I recall, older drivers based on S3's code did not support gamma correction properly. Alex --- Thibault Mondary [EMAIL PROTECTED] wrote: Hi, I am using savage driver from savage-2 cvs but it seems the switch Gamma x y z in XF86Config Monitor section doesn't make anything. In Xfree log, we can see parameters are used, but visually there is no difference between gamma 1.0 1.0 1.0 and gamma 0.5 0.5 0.5 Thib. __ Do you Yahoo!? Win a $20,000 Career Makeover at Yahoo! HotJobs http://hotjobs.sweepstakes.yahoo.com/careermakeover --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] RE: [Dri-devel] Memory management of AGP and VRAM
Egbert Eich wrote: However chipset probing/display device probing and mode setting isn't required to live in kernel space. Portability and system stability arguments speak against it. In fact only Apple MAC users seem to advocate this idea to be able to an initial video mode on their systems. Allow me to speak up for users of IBM pSeries hardware or Sun SPARC hardware. Users of those systems face exactly the same issues as Mac users. I imagine most embedded systems will be in the same boat. Being forced to use a serial console for early boot messages is so 1980's. ;) The kernel doesn't need to have support for everything, but I think it's important to have at least minimal support. --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] Memory management of AGP and VRAM
Moving mode setting from the Xsever does not necessarily mean it has to go into the kernel. I agree. The thing I am worried about (just speaking about the mode setting part here) is that we end up with 2 defined APIs. One for the mode setting, done as a user library, and another for the kernel part that is really tiny. That assumes a split that will be hard to agree on. As long as we only define one entry point, everyone can be happy. i.e. define a pretty small library API in user space and let the driver writer decide where to split the unprivileged library code from the privileged (kernel in most cases) part. But that means that there is no guarantee what the actual kernel API looks like, it becomes driver dependent. In my mind you have 3 modules. 1: Privileged code that can access hardware directly 2: Unprivileged code that provides a minimal known mode API and any number of unknown APIs specific to hardware. 3: DD code that is part of the higher level library. XFree driver or Mesa driver etc. The API between 1 and 2 is undefined. Any kernel/user split could be used. The goal for the driver writer is to get as much in module #2 but you could put all the code kernel-side and just make module #2 a function wrapper for your ioctls if you wanted. The API between 2 and 3 has only a tiny definition. Small mode setting, maybe some tiny 2d drawing just to be nice and nothing else. The rest is driver dependent and only gets used by module 3. Module 3 is just the DD layer or XFree, or the DD layer of Mesa. Doesn't matter what high level design ends up winning in the end. People seem to advocate to utilize OpenGL for 2D rendering on modern chipsets. It remains to be seem how feasable this alternative is. However a solution for this already exists. If we are talking about 3D rendering a solution for this already in the making with standalone MESA. For 2D rendering X has a rather smart infrastructure to map X drawing requests onto those 2D primitives that are commonly provided by chipsets. The driver part there is rather lightweight as most of the work is done by this abstraction layer. It would be great if this interface could be kept for chipsets that need 2D acceleration. I agree. The high level stuff will probably need several code paths depending on chip capabilities. You are talking about APIs used above module 3 which should all be possible given the correct 1 and 2. 1) A small, device-independent, API that can be used to set modes and do some very simple rendering. I would suggest get, set, put, copy. Do you suggest to accelerate these and put the acceleration for them into the kernel? This would mean a longer path from user space. Since the these operations typically don't deal with huge areas this may mean a signifficant performance penalty. Not making any claim as to where they would be (module 1 or 2). Just indicating that there would be a small defined API and everything else is undefined. Having a defined way to do some primitives would allow a completely device independent X server written today to limp along on hardware of tomorrow. Some minimal mode setting is a must have part of that defined API. Get, set, put, copy seems a safe set of helpers. Just a way to get some minimal performance until you can get an actual DD driver created or installed. Experience has shown that there is almost no way to desing an API so generic that it can effectively deal with new features that come along in the future in an effective way. I agree. I think we are on the same page. A minimal set of features is all that would be part of the defined mode setting API. It is just a question of if some of the multi-head concepts are generic enough to be part of that defined set. --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] Memory management of AGP and VRAM
Sottek, Matthew J writes: I for one have been waiting to see much of the graphics driver moved to the kernel as well. From a vendor perspective there is quite a lot to be gained. 1) If the mode setting can be removed from the X server then we can leverage that module for whatever graphics system is required. Some times we need an X server, some times we need something more like a framebuffer. Putting this in one place is a must. Moving mode setting from the Xsever does not necessarily mean it has to go into the kernel. 2) Providing one place for rendering code would be nice too. We cannot assume that X is the way to go for all customers. If there were a place to put the device dependent rendering code (kernel module or low level library) then we could write X servers or custom graphics interfaces to use that library. People seem to advocate to utilize OpenGL for 2D rendering on modern chipsets. It remains to be seem how feasable this alternative is. However a solution for this already exists. If we are talking about 3D rendering a solution for this already in the making with standalone MESA. For 2D rendering X has a rather smart infrastructure to map X drawing requests onto those 2D primitives that are commonly provided by chipsets. The driver part there is rather lightweight as most of the work is done by this abstraction layer. It would be great if this interface could be kept for chipsets that need 2D acceleration. 3) Some times you can just do the job easier or better from kernel space. Trapping interrupts instead of polling can save huge amounts of CPU cycles for some usage scenarios. Power management is easier. Sometimes the hardware needs some special memory considerations etc. No need to really harp on any of the details, it is just nice to have the full power of the OS when/if you need it. I think the best way to make everyone happy is to try to achieve two things. I would argue that as little as possible should go into the kernel. There is no question that the resource handling for buses, DMA and irq needs to live within the kernel. The same is true for code that uses DMA. However chipset probing/display device probing and mode setting isn't required to live in kernel space. Portability and system stability arguments speak against it. In fact only Apple MAC users seem to advocate this idea to be able to an initial video mode on their systems. 1) A small, device-independent, API that can be used to set modes and do some very simple rendering. I would suggest get, set, put, copy. Do you suggest to accelerate these and put the acceleration for them into the kernel? This would mean a longer path from user space. Since the these operations typically don't deal with huge areas this may mean a signifficant performance penalty. That would allow the kernel to render consoles or oopsen regardless of the mode (debugging the kernel on top of your X session?), and allow for any API of the month to make use of some very basic functionality. Mode setting should just be small as well, leave all the one-off features for extensions. No need to clutter an API with features that are rare. Although the fbdev is already available, I wouldn't suggest that it is a great platform to build on. The mode setting API is really not very good and it does not have modern concepts of twin, clone etc. I think a clean slate design that didn't try to accomplish everything in device independent manner could be a much more attractive target. Experience has shown that there is almost no way to desing an API so generic that it can effectively deal with new features that come along in the future in an effective way. Soon after XFree86 4 came out graphics cards with what you call twin view became available. We had to kludge around to make this work in XFree86. It was difficult but it was possible because the 4.x driver design was such that the driver was the controlling instance of everything - well, almost everything. All the pieces where this was not entirely true - and the number of heads per chipset was an example here - proved to be nightmares. Therefore the mode setting API should provide a minimal set of standard features a set of optional features (which may evolve over time) and allow a chipset specific API that may - over time - move into the optional features. 2) A mechanism to make all the device dependent extensions your heart desires. Then the X servers, opengl libs, etc can just have a DD component to access the hardware specific API. The more things you try to have a device independent API for, the more problems you will have trying to get agreement. Leave the API's to themselves. We should be trying to create a driver model, not a new graphics API. Ogl, X11, DirectFB, etc should be out of scope. Right. My experience has certainly shown that almost no assumption we have made in the past remained
Re: [Dri-devel] R200 TexCoord3f patch for cubemaps
On Thu, 2004-05-06 at 02:54, Ian Romanick wrote: Michel Dnzer wrote: On Wed, 2004-05-05 at 04:48, Ian Romanick wrote: There's a VTX_DISCRETE_FOG_SEL bit in the SE_TCL_OUTPUT_VTX_COMP_SEL register that the code doesn't seem to handle yet? SE_TCL_OUTPUT_VTX_COMP_SEL or SE_TCL_OUTPUT_VTX_FMT_0? There isn't even a bit for fog in SE_TCL_OUTPUT_VTX_COMP_SEL in r200_reg.h. It's bit 24. The description says 'Select the computer descrete (sic) fog value'. -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] [Bug 314] 3D support for Radeon IGP chips
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter your comments there. http://bugs.xfree86.org/show_bug.cgi?id=314 --- Additional Comments From [EMAIL PROTECTED] 2004-05-08 00:46 --- I just patched XFree86 4.4.0 sources with XFree86-4.4.0-radeon-igp.patch. First of all, is there a typo in line 569: unsigned long fb_location; ? shouldn't it be unsigned long fb_base; ? anyway, the drm-module didn't compile before i changed fb_location = fb_base. The drm-module radeon.ko loads ok (eg. no error messages), but it doesnt work. XFree86.log.0: (II) Primary Device is: PCI 01:05:0 (--) Assigning device section with no busID to primary device (--) Chipset ATI Radeon IGP320M (U1) 4336 found drmOpenDevice: minor is 0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is -1, (Unknown error 999) drmOpenDevice: open result is -1, (Unknown error 999) drmOpenDevice: Open failed (II) RADEON(0): [drm] drmOpen failed (EE) RADEON(0): [dri] DRIScreenInit failed. Disabling DRI. (II) RADEON(0): Direct rendering disabled lsmod: radeon128960 0 ati_agp 6348 1 And yes, the radeon.ko which modprobe loads, is the same than xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/radeon.ko. I tryed to use the radeon.ko which ships with my kernel (2.6.5), and it reported something when loaded with modprobe: [drm] Initialized radeon 1.9.0 20020828 on minor 0 Even the XFree86.0.log says everything is fine for a while: drmOpenDevice: minor is 0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 5, (OK) drmOpenDevice: minor is 0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 5, (OK) drmOpenDevice: minor is 0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 5, (OK) drmGetBusid returned '' (II) RADEON(0): [drm] created radeon driver at busid PCI:1:5:0 (II) RADEON(0): [drm] added 8192 byte SAREA at 0xdd91 (II) RADEON(0): [drm] mapped SAREA 0xdd91 to 0x44267000 (II) RADEON(0): [drm] framebuffer handle = 0xf000 (II) RADEON(0): [drm] added 1 reserved context for kernel (II) RADEON(0): [agp] Mode 0x0f000204 [AGP 0x1002/0xcab0; Card 0x1002/0x4336] (II) RADEON(0): [agp] 8192 kB allocated with handle 0x0001 (II) RADEON(0): [agp] ring handle = 0xec00 (II) RADEON(0): [agp] Ring mapped at 0x44269000 (II) RADEON(0): [agp] ring read ptr handle = 0xec101000 (II) RADEON(0): [agp] Ring read ptr mapped at 0x4436a000 (II) RADEON(0): [agp] vertex/indirect buffers handle = 0xec102000 (II) RADEON(0): [agp] Vertex/indirect buffers mapped at 0x4436b000 (II) RADEON(0): [agp] GART texture map handle = 0xec302000 (II) RADEON(0): [agp] GART Texture map mapped at 0x4456b000 (II) RADEON(0): [drm] register handle = 0xe850 (II) RADEON(0): [dri] Visual configs initialized (II) RADEON(0): [drm] installed DRM signal handler (II) RADEON(0): [DRI] installation complete (WW) RADEON(0): Mismatched FB location. Incorrect version of DRM kernel driver $ (II) RADEON(0): [drm] removed 1 reserved context for kernel (II) RADEON(0): [drm] unmapping 8192 bytes of SAREA 0xdd91 at 0x44267000 (II) RADEON(0): Direct rendering disabled Any hints? -- Configure bugmail: http://bugs.xfree86.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
