Re: Solo Xgl..
On Sun, 2005-02-20 at 18:42 -0500, Jon Smirl wrote: On Mon, 21 Feb 2005 10:00:04 +1100, Dave Airlie [EMAIL PROTECTED] wrote: It's also a bad hack that the current miniglx sample_server has to be run then the X server, current miniglx I don't think supports rendering in its server application.. It doesn't support it and that's another reason to kill it. Next thing you are going to run into is lack of FBO (ie render-to-texture, frame buffer object, superbuffers). Hint, hint Ian. That leads to one missing piece to ultimately merge the fb layer (mode setting) and the kernel DRM (command processing), which is a video memory manager that is independant from the client (X server). --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
32/64-bit ioctl compatibility
I have been looking through Egbert Eich's patch to add 32-bit compatibility code for the DRM ioctls on 64-bit platforms. First off, has anyone updated the patch lately? The patch adds an extra field to the drm_map_t to handle the problem of the `handle' field being basically a kernel virtual address which gets exposed to userland. His patch seems to go to considerable lengths to translate between 32-bit handles and 64-bit handles, and the extra field in the drm_map_t basically means a change to the ABI, which I'd rather avoid if possible. There is also the `offset' field, which seems to have a similar function in terms of distinguishing between different regions of the address space. The `handle', though, seems to be always a vmalloc'd or ioremap'd address. How does userspace use the handle? Does userspace treat it as a purely opaque value? Could we perhaps synthesize a 32-bit handle cheaply by combining the offset and type fields? (or even just use offset 12 perhaps?) Paul. --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Offtopic: Quake 3
From a google cached copy of the howto. The idsoftware ftp site seems to be gone, but I'm certain you can find the latest point release around. Native Linux Games: Quake 3 Arena-HowTo Author: cairon Published: 2004-02-20 Read 15026 times Size 6.35 KB Author: cairon Language: English Last Change: 2004-02-20 Version: 1.0 This howto is published under the GNU Free Documentation License. Copyright (c) 2004 linux-gamers.net. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license can be found in the section entitled GNU Free Documentation License. Warning: This HOWTO comes with no explicit or implicit warranty whatsoever. Use at you own risk! This HowTo describes how to install, update and configure Quake 3 Arena under Linux by using an Windows-version of the game. 1) Requirements 2) Installation 3) Get Punkbuster and OSP running 4) Appendix 1) Requirements First of all the requirements which must be fulfilled: -3D-Acceleration on your machine is installed and working. -Soundsystem is installed and working. -You have a CD of Quake 3 Arena and an original key of the game. -You have access to the internet (or someone who can download the needed files for you). Your machine fulfilles the hardware requirements of the game. 2) Installation First, you have to create a folder in which you can copy the files of the game. You do this by opening a shell and type in (as root): # mkdir -p /usr/local/games/quake3/baseq3 This will create the folders quake3 and the subfolder baseq3 in /usr/local/games Then insert the Quake 3 Arena-CD in your local CD- or DVD-ROM and mount it # mount /media/cdrom (for /media/cdrom use the place, where you have mounted your CDRom-Drive) From the CD copy the file pak0.pk3 into the subfolder baseq3 # cp /media/cdrom/Quake3/baseq3/pak0.pk3 /usr/local/games/quake3/baseq3 This could take some time time, the file is about 460 MB. After the file is copied, the CD no longer is required. In the meantime, connect to the internet and download the latest pointrelease. At the time of writing the most recent pointrelease is 1.32b. Make sure that you have 1.32b, with the b, if you only have 1.32, it often causes problems with the mouse. If you take an older version, you are not compatible to most of the servers in internet and LAN (pointreleases of Quake 3 Arena are not compatible to each other). One adress where you can grab it is is software itself: ftp://ftp.idsoftware.com/idstuff/quake3/linux/linuxq3apoint-1.32b-3.x86.run download it and save it into /usr/local/games/quake3 When it is finished, go in the shell to the directory quake3 # cd /usr/local/games/quake3 There, find the pointrelease and execute it: # sh /usr/local/games/quake3/linuxq3apoint-1.32b-3.x86.run Then follow the instructions on your screen (you can answer Yes to every question you are asked during the installation). 3) Get Punkbuster and OSP running Unfortunately, in the latest pointrelease the Anti-Cheat-Software punkbuster was integrated, which is automatically installed with the pointrelease. Normally, punkbuster should update itself yet normally it doesnt. The easiest way to do it manually is to download the updatetool of punkbuster, pbweb. Download it, and save it in /home/youruser/.q3a/pb (.q3a - mind the dot - is a hidden folder so if the Save dialog doesn't show it move it there manually). You must save it there, otherwise it will not work. Now make it executable by typing chmod +x / home/youruser/.q3a/pb/pbweb.x86 Then execute pbweb.x86 by changing into the bp folder cd /home/youruser/.q3a/pb and running ./pbweb.x86 Now punkbuster will bring itself up-to-date - this can take some time even if you are on broadband, seems like the responding server is rather slow. Thats all you have to do to have a running version of Quake 3 Arena. For to start Quake 3 Arena type quake3 in a shell or use the links in your desktopmanager. To play online with punkbuster, go into the menu of Quake 3 Arena, Multiplayer, and activate punkbuster- But who wants to play base-q3?? Nearly no one, I think The mostly played (and must needed) modification (mod) in Quake 3 Arena is OSP. OSP stands for Orange Smoothie Productions, and that is where you can download it at http://games.xs4all.nl/downloads/downloads.php?dl=39 OSP brings you a couple of new maps, now modes of playing and many more. Installing OSP is very simple: Download the latest version of OSP (at the time of writing 1.03a), save it to your harddisk, and extract the .zip-file into your /usr/local/games/quake3 folder. After this, you should have a new subfolder under /usr/local/games/quake3, the folders name is osp. Thats all For other mods, do it identical. 4) Appendix For
Re: [r300] Radeon 9600se mostly working..
Hi John, Thank you for testing :)) More below. On Mon, 21 Feb 2005, John Clemens wrote: So I've been lurking for a while following the r300 work and decided to give it a go on my fanless 9600se (RV350 AP). How much memory do you have ? What kind of CPU and motherboard ? - glxinfo states r300 DRI is enabled. (AGP4x, NO-TCL) - glxgears gives me about 250fps with drm debug=1, ~625fps without debug on. - tuxracer runs ok at 640x480 fullscreen - ice textures look psychadelicly blue - at 1280x1024, (and somewhat at 800x600 windowed), i get these errors: [drm:radeon_cp_dispatch_swap] *ERROR* Engine timed out before swap buffer blit Any pointers on what causes that? This is with Xorg cvs, Mesa cvs, r300 cvs, as of 4 hours ago. I'm guessing the X server or mesa isn't filling the buffer up fast enough at higher resolutions...but I'm new to devlopment so i don't know which buffer that would be.. The swap buffer blit is just a copy - for example a copy from back buffer to front buffer. Since the engine timed out before swap buffer blit it means that the commands before it were at fault. Which is puzzling as you point out that everything works in 640x480. I wonder whether the lockup detection logic is at fault - we simply wait a fixed amount of time for the engine to become idle. Perhaps it would be better to actually monitor the CP engine progress, for example by looking for changes in current ring pointer (i.e. wait and check whether the value changed). If the ring pointer does not change declare a lockup. What does everyone think ? thank you Vladimir Dergachev thanks, john.c -- John Clemens http://www.deater.net/john john at deater.net I Hate Quotes -- Samuel L. Clemens --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] Radeon 9600se mostly working..
Hi Vladimir, On Mon, 21 Feb 2005, John Clemens wrote: give it a go on my fanless 9600se (RV350 AP). How much memory do you have ? What kind of CPU and motherboard ? Duron 1.8G, 256MB ddr, old(ish) via km266 motherboard in a shuttle sk41g. Gentoo. The card has 128Mb ram. - glxinfo states r300 DRI is enabled. (AGP4x, NO-TCL) - glxgears gives me about 250fps with drm debug=1, ~625fps without debug on. should I be concerned that these fps are too low? others seem to be reporting around 1000.. - tuxracer runs ok at 640x480 fullscreen - ice textures look psychadelicly blue - at 1280x1024, (and somewhat at 800x600 windowed), i get these errors: [drm:radeon_cp_dispatch_swap] *ERROR* Engine timed out before swap buffer blit ... The swap buffer blit is just a copy - for example a copy from back buffer to front buffer. Since the engine timed out before swap buffer blit it means that the commands before it were at fault. Which is puzzling as you point out that everything works in 640x480. Just to elaborate: 640x480 runs fine. at 800x600 windowed, it plays fine, but if a scene gets more complicated i see some jerkyness.. i.e., the scene freezes for a second or two and then jumps ahead, and i get a few messages in the log. At 1280x1024, this happens all the time, so it appears the game is locked, and I get a stream of those messages in the log file. alt-F switching to the console works, and switching back i get about 2 seconds more of movement, and then soft-lock again (persumably because the card re-inits on VC switch). I can switch to the VC and kill it and all's fine. Judging from what you're saying, the card isn't locked, it just isn't able to draw a full scene before it times out. Who is responsible for drawing to this buffer? r300, mesa or x? I just grabbed the CVS trees and did a make, I think mesa by default might be compiled with -O -g, would it be better to recomile it with just -O2? I wonder whether the lockup detection logic is at fault - we simply wait a fixed amount of time for the engine to become idle. Perhaps it would be better to actually monitor the CP engine progress, for example by looking for changes in current ring pointer (i.e. wait and check whether the value changed). If the ring pointer does not change declare a lockup. What does everyone think ? Seems reasonable. What's the downside if you if you swap a half-draw buffer to the fore and then start drawing a new one? tearing? john.c -- John Clemens http://www.deater.net/john john at deater.net I Hate Quotes -- Samuel L. Clemens --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Solo Xgl..
On Mon, 2005-02-21 at 14:08 -0500, Jon Smirl wrote: On Mon, 21 Feb 2005 19:07:55 +1100, Benjamin Herrenschmidt [EMAIL PROTECTED] wrote: That leads to one missing piece to ultimately merge the fb layer (mode setting) and the kernel DRM (command processing), which is a video memory manager that is independant from the client (X server). Now you know why I have been making all those posts about merging DRM/fbdev for the last year while everyone was calling me crazy. mesa-solo has to join DRM/fbdev together to get the foundation that it needs. Heh, well, I at least knew it all along ;) Another part of the goal is that the XGL server does not need to run as root. I've recently posted code to fb-devel list that allows modes to be set without being root. I'm also trying to sort out reseting of secondary cards using fbdev. Other areas that need work is hardware cursor and fixing radeonfb to support two heads and merged fb. For non-root, that is fine as long as there is some console ownership management, and proper arbitration with engine users when a mode switch is triggered. But we already discussed all of this a while ago ;) I'm sorry I didn't have time at all on my side to work on those things. Hardware support, radeonfb multihead, etc... is all trivial to do once we have proper infrastructure. fbdev need a bit of overhaul in it's current state (at least proper mecanism for picking where to allocate the second head and ways for userland to know which framebuffers are tied together). Ben. --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
R300 lockups...
FYI, I've now tried neverputt in a window, instead of fullscreen, and I'm getting the same lockups as I was previously getting (full lockups, including mouse, requiring me to ssh in a reboot). It finally occurred to me to check dmesg: [drm:radeon_cp_dispatch_swap] *ERROR* Engine timed out before swap buffer blit I got that line repeated over and over :-) Adam --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Solo Xgl..
On Tue, 22 Feb 2005 08:04:14 +1100, Benjamin Herrenschmidt [EMAIL PROTECTED] wrote: On Mon, 2005-02-21 at 14:08 -0500, Jon Smirl wrote: On Mon, 21 Feb 2005 19:07:55 +1100, Benjamin Herrenschmidt [EMAIL PROTECTED] wrote: That leads to one missing piece to ultimately merge the fb layer (mode setting) and the kernel DRM (command processing), which is a video memory manager that is independant from the client (X server). Now you know why I have been making all those posts about merging DRM/fbdev for the last year while everyone was calling me crazy. mesa-solo has to join DRM/fbdev together to get the foundation that it needs. Heh, well, I at least knew it all along ;) Another part of the goal is that the XGL server does not need to run as root. I've recently posted code to fb-devel list that allows modes to be set without being root. I'm also trying to sort out reseting of secondary cards using fbdev. Other areas that need work is hardware cursor and fixing radeonfb to support two heads and merged fb. For non-root, that is fine as long as there is some console ownership management, and proper arbitration with engine users when a mode switch is triggered. But we already discussed all of this a while ago ;) I'm sorry I didn't have time at all on my side to work on those things. Hardware support, radeonfb multihead, etc... is all trivial to do once we have proper infrastructure. fbdev need a bit of overhaul in it's current state (at least proper mecanism for picking where to allocate the second head and ways for userland to know which framebuffers are tied together). If we are going to start fresh so to speak, why even mess with mergedfb in the new fb/drm driver? it would make more sense to just update the 2d and 3d engine offsets to point to whichever framebuffer is active. for dualhead the offset would just be updated along with the other 3d state just like with multiple 3d apps. We could also use separate tiled surfaces for each frambuffer so we wouldn't be limited to 2kx2k. Then we wouldn't have any of the limitations of mergedfb. Alex Ben. --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 32/64-bit ioctl compatibility
First off, has anyone updated the patch lately? Nope, I think it needs to go back to the drawing board... The biggest problem with SuSEs patch is that is was written by the looks of it to cover the DRM and Mesa making changes to both to achieve the solution, this isn't a way to acheive backwards compatiblity... How it has to work, is taking a current DRI 32-bit binary, build a drm that should support 64-bits.. see does it work with the current 32-bit one... then write a Mesa patch that supports 64-bits and make it work on the drm you just made... also take a 64-bit pure drm and 64-bit pure DRI and make sure they work... Changing the drm and Mesa at once incompatibly isn't going to get past me, and I haven't proven that Egberts patch isn't backwards compat, but nobody has proven to me that it doesn't break anything, and as I have no access to any 64-bit hardware it is up to other people to convince me ... Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie Linux kernel - DRI, VAX / pam_smb / ILUG --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Solo Xgl..
On Mon, 2005-02-21 at 16:11 -0500, Alex Deucher wrote: If we are going to start fresh so to speak, why even mess with mergedfb in the new fb/drm driver? it would make more sense to just update the 2d and 3d engine offsets to point to whichever framebuffer is active. for dualhead the offset would just be updated along with the other 3d state just like with multiple 3d apps. We could also use separate tiled surfaces for each frambuffer so we wouldn't be limited to 2kx2k. Then we wouldn't have any of the limitations of mergedfb. I totally agreed. In fact, we had this discussion about mergedfb issues with friends here yesterday and came to the conclusion that it was a nice hack, but not something we want to stick with eternally. We still need a good allocator for video memory though ;) When talking about which framebuffer are tied together, I meant a clean way for userland clients to know which /dev/fb's form a pair on a given card (for access arbitration/discipline issues) and properly map /dev/fb'd to DRI device nodes (since we probably want to keep the existing separate ioctl APIs for backward compatibility at least, just build on top of it). Ben. --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Solo Xgl..
On Tue, 22 Feb 2005 08:04:14 +1100, Benjamin Herrenschmidt [EMAIL PROTECTED] wrote: Hardware support, radeonfb multihead, etc... is all trivial to do once we have proper infrastructure. fbdev need a bit of overhaul in it's current state (at least proper mecanism for picking where to allocate the second head and ways for userland to know which framebuffers are tied together). Ben, since I'm not getting any help on LKML maybe you can answer this. Secondary cards needs reset. After looking at a bunch of fbdev drivers their code assumes the card has been reset when their probe() function runs. So this means that we have to run the VBIOS reset before probe is called. So where can I hook up the call to run the VBIOS up in the kernel? You can't trigger it on module load since the module may support multiple identical adapters. One adapter may already have the module loaded and then a second shows up via hotplug. In this case the module won't get loaded again and the second card doesn't get reset. If using a user space reset program what do you do if the user space program is missing or does not complete running? Somehow you have to stop the probe function from being called. Another case, you have a card and load the module for it, this causes reset. Now unload the module and load it again. This probably should not reset the card a second time. You also have to make sure you don't reset the primary card. One solution is to track in pci_dev if the card has been reset. This preserves the state across module load/unload. I'm then tempted to put an in-kernel emu86 (I have a 40K one) into the pci driver. PCI would use this to reset the card before calling probe(). If the VBIOS/emu86 has an error it simply wouldn't call the probe function. Doing this in-kernel makes everything synchronous but GregKH would probably have some choice words about the emulator in the PCI driver. I am leaning toward putting this into the PCI driver. At boot the PCI driver would reset any cards it finds. The PCI driver also implements hotplug so now I have a place to do reset before calling probe in this case. Doing it in-kernel fixes the synchronization problem. Right now there is no way to suspend calling the probe function while we wait for a hotplug event to finish. I have all of the pieces needed to build this. I just can't figure out where to hook it into the kernel. Worst case is that I have to go modify 75 framebuffer drivers to explicitly support reset. -- Jon Smirl [EMAIL PROTECTED] --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Solo Xgl..
On Monday 21 February 2005 20:17, Jon Smirl wrote: I have all of the pieces needed to build this. I just can't figure out where to hook it into the kernel. Worst case is that I have to go modify 75 framebuffer drivers to explicitly support reset. Wandering off-topic here... You keep saying 75 or other big numbers. Isn't the number closer to 10? By which I mean, don't we really only care about structural changes to the fbdev drivers that have a corresponding drm driver? That would leave: tdfx, radeon, rage128, mach64, mga, sis, unichrome, intel, savage... and maybe someday s3virge and trident too. I don't want to get too bogged down on this point, but I'd forgotten to ask this at xdevconf. I understand the appeal of having every fbdev driver behave the same, but it might be an easier pitch to only try to change the drivers that need this for 3D. If it's a stupid question feel free to ignore me. - ajax pgpTeHsy7gANL.pgp Description: PGP signature
Re: Solo Xgl..
On Mon, 21 Feb 2005 20:34:36 -0500, Adam Jackson [EMAIL PROTECTED] wrote: On Monday 21 February 2005 20:17, Jon Smirl wrote: I have all of the pieces needed to build this. I just can't figure out where to hook it into the kernel. Worst case is that I have to go modify 75 framebuffer drivers to explicitly support reset. Wandering off-topic here... You keep saying 75 or other big numbers. Isn't the number closer to 10? By which I mean, don't we really only care about structural changes to the fbdev drivers that have a corresponding drm driver? That would leave: tdfx, radeon, rage128, mach64, mga, sis, unichrome, intel, savage... and maybe someday s3virge and trident too. I don't want to get too bogged down on this point, but I'd forgotten to ask this at xdevconf. I understand the appeal of having every fbdev driver behave the same, but it might be an easier pitch to only try to change the drivers that need this for 3D. If I make structural changes to the fb-dev core I have to fix all of the drivers even though we only use 10 of them. I guess I could make the fixes for the 10 we use and just leave the others alone. Plus I would like to get a software mesa solution running on the dumb framebuffer drivers. I am only implementing the functions in the 10 drivers that we need. The rest get stubs. An example of a change that would impact all of the drivers, splitting fb_info into a fb_device and fb_head pieces. The current fb_info structure assumes one card and one head. If you copy it for two heads you end up copying a bunch of fields that are not meant to be copied since they point at things that there is only one per device. Nobody is arguing about changing the 75 drivers, it's just a lot of work. Of course if I can come up with a scheme that avoids touching the drivers I'll use it. -- Jon Smirl [EMAIL PROTECTED] --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R300 lockups...
On Mon, 21 Feb 2005, Adam K Kirchhoff wrote: FYI, I've now tried neverputt in a window, instead of fullscreen, and I'm getting the same lockups as I was previously getting (full lockups, including mouse, requiring me to ssh in a reboot). It finally occurred to me to check dmesg: [drm:radeon_cp_dispatch_swap] *ERROR* Engine timed out before swap buffer blit Hmmm - can you try reducing the window size of neverputt ? And, perhaps, the refresh rate and resolution of your screen ? thank you ! Vladimir Dergachev I got that line repeated over and over :-) Adam --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
POSTing of video cards (WAS: Solo Xgl..)
Ben, since I'm not getting any help on LKML maybe you can answer this. Secondary cards needs reset. After looking at a bunch of fbdev drivers their code assumes the card has been reset when their probe() function runs. So this means that we have to run the VBIOS reset before probe is called. I'm putting back LKML on CC since I intended to reply to your post there once I got a bit of time. No, we can't really do that _before_ probe is called. It's the responsibility of the driver to do what it needs at probe time or later. Some drivers need that reset (and not that many in fact), some don't. We may provide a helper to use from the probe() for that purpose, to make things easier. Wether the reset code is kernel based or userland based, I would avoid have it run synchronously anyway. If a driver detects that it's card hasn't been properly initialized by the firmware (and the driver should be able to detect that), I suggest it's probe routine calls the appropriate helper, providing it with ways to get to the ROM (in some case, the same helper will be needed for resume from sleep, and the ROM may not be the PCI BAR one, but the memory shadow, though that will not always work afaik). Look at the firmware download helper, that's very similar. I want an asynchronous interface though (that is you get a callback when the reset is complete or timed out) rather than synchronous since it's wrong to synchronously rely on userland beeing available (power management, pre-root mount, etc...) So where can I hook up the call to run the VBIOS up in the kernel? You can't trigger it on module load since the module may support multiple identical adapters. One adapter may already have the module loaded and then a second shows up via hotplug. In this case the module won't get loaded again and the second card doesn't get reset. If using a user space reset program what do you do if the user space program is missing or does not complete running? Somehow you have to stop the probe function from being called. That's ok. We deal with that in the firmware loader code already. Just timeout or check for errors from call_usermodehelper. You basically run the user program and wait for it to write a reply via sysfs. In fact, the existing firmware loading facility could be re-used. Another case, you have a card and load the module for it, this causes reset. Now unload the module and load it again. This probably should not reset the card a second time. You also have to make sure you don't reset the primary card. It's up to each driver to detect wether it's card need to be POSTed or not. Anything else would mean infinite breakage. One solution is to track in pci_dev if the card has been reset. This preserves the state across module load/unload. I'm then tempted to put an in-kernel emu86 (I have a 40K one) into the pci driver. PCI would use this to reset the card before calling probe(). If the VBIOS/emu86 has an error it simply wouldn't call the probe function. Doing this in-kernel makes everything synchronous but GregKH would probably have some choice words about the emulator in the PCI driver. No, again, it's up to the driver to decide wether it needs to POST or not (I prefer that to reset). I have no preference for the emulator to be in-kernel or userland. I suppose it's easier in userland, just re-using the existing infrastructure for firmware loading. I am leaning toward putting this into the PCI driver. At boot the PCI driver would reset any cards it finds. The PCI driver also implements hotplug so now I have a place to do reset before calling probe in this case. Doing it in-kernel fixes the synchronization problem. Right now there is no way to suspend calling the probe function while we wait for a hotplug event to finish. I have all of the pieces needed to build this. I just can't figure out where to hook it into the kernel. Worst case is that I have to go modify 75 framebuffer drivers to explicitly support reset. No. You don't. A lot of them simply don't care. Just adapt radeonfb, and maybe the others ATIs and rivafb, period. If somebody want to adapt to your facility, it's up to that person to adapt the framebuffer of their dream. You provide infrastructure that _adds_ a functionality not previously present. You don't need to implement it in all drivers yourself, just do it in a few that matter, and let people who want the feature catch up as long as old drivers don't _lose_ functionality. Also, a lot of those FB's are embedded things, or ppc/pmac things, etc... and they simply don't fit into your scheme anyway (and mostly don't have the problem in the first place). Cheers, Ben. --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click --
Re: [Linux-fbdev-devel] Resource management.
Do you see any other solution to this then? You could build this inside of the DRM framework which already supports DMA and memory management. DRM doesn't really know anything about 3D, it just knows how to send commands to the graphics hardware. It's the mesa layer in user space that knows about 3D. There is a lot of code inside DRM to stop a DRM user from using the DMA hardware to play with kernel memory and gain root priv. fbdev will need the same protection if it starts using DMA. I have CC the dri list to discuss the issues. I have looked at the DRI code. I know merging dri and fbdev infrastructres has been discussed before. There are a few issues that have always prevented this. Now I'm going to go over the issues. 1. Lots of work that would take lots of time. To my knowledge all fbdev developers work in there spare free time. No one does this for a living. 2. Sharing of headers. The dri headers are isolated in the drm directory. I totally understand why :-) It makes merging easier for them. The disadvantage is no one in the fbdev can use them easily :-( 3. DRM has way to much functionality for most embedded devices. I have talked to embedded guys before and they want a simple api to work with. By default DRM builds in everything. A simple api mean alot to those guys. Plus the extra built in code bloat takes up to much space which is precious on embedded devices. If a devices doesn't support dma then the dma code doesn't need to be built in. 4. Which comes to the next point. The code is not modular enough. Take drm_bufs.c. Everything is a ioctl function. This has a few disadvantages. One is the fbdev layer couldn't just link into it so fbcon could use it. The second is it's not easy to take advantage of things like sysfs. If you could untangle the code somewhat it would make life so much easier. That would include making life easier for OS ports. 5. The license issue. The DRI code is GPL and additional rights. What is that? For the fbdev layer we would need a layer on top of the drm data structures because we need to know things in the kernel to draw images for font characters i.e how much byte padding is need for images. --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: POSTing of video cards (WAS: Solo Xgl..)
On Tue, 22 Feb 2005 14:12:48 +1100, Benjamin Herrenschmidt [EMAIL PROTECTED] wrote: Ben, since I'm not getting any help on LKML maybe you can answer this. Secondary cards needs reset. After looking at a bunch of fbdev drivers their code assumes the card has been reset when their probe() function runs. So this means that we have to run the VBIOS reset before probe is called. I'm putting back LKML on CC since I intended to reply to your post there once I got a bit of time. No, we can't really do that _before_ probe is called. It's the responsibility of the driver to do what it needs at probe time or later. Some drivers need that reset (and not that many in fact), some don't. We may provide a helper to use from the probe() for that purpose, to make things easier. Wether the reset code is kernel based or userland based, I would avoid have it run synchronously anyway. If a driver detects that it's card hasn't been properly initialized by the firmware (and the driver should be able to detect that), I suggest it's probe routine calls the appropriate helper, providing it with ways to get to the ROM (in some case, the same helper will be needed for resume from sleep, and the ROM may not be the PCI BAR one, but the memory shadow, though that will not always work afaik). Look at the firmware download helper, that's very similar. I want an asynchronous interface though (that is you get a callback when the reset is complete or timed out) rather than synchronous since it's wrong to synchronously rely on userland beeing available (power management, pre-root mount, etc...) So where can I hook up the call to run the VBIOS up in the kernel? You can't trigger it on module load since the module may support multiple identical adapters. One adapter may already have the module loaded and then a second shows up via hotplug. In this case the module won't get loaded again and the second card doesn't get reset. If using a user space reset program what do you do if the user space program is missing or does not complete running? Somehow you have to stop the probe function from being called. That's ok. We deal with that in the firmware loader code already. Just timeout or check for errors from call_usermodehelper. You basically run the user program and wait for it to write a reply via sysfs. In fact, the existing firmware loading facility could be re-used. Another case, you have a card and load the module for it, this causes reset. Now unload the module and load it again. This probably should not reset the card a second time. You also have to make sure you don't reset the primary card. It's up to each driver to detect wether it's card need to be POSTed or not. Anything else would mean infinite breakage. One solution is to track in pci_dev if the card has been reset. This preserves the state across module load/unload. I'm then tempted to put an in-kernel emu86 (I have a 40K one) into the pci driver. PCI would use this to reset the card before calling probe(). If the VBIOS/emu86 has an error it simply wouldn't call the probe function. Doing this in-kernel makes everything synchronous but GregKH would probably have some choice words about the emulator in the PCI driver. No, again, it's up to the driver to decide wether it needs to POST or not (I prefer that to reset). I have no preference for the emulator to be in-kernel or userland. I suppose it's easier in userland, just re-using the existing infrastructure for firmware loading. another advantage of the emulator would be that PC vga cards could be used in non-x86 platforms, which I'm sure would be quite popular... Alex --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] Resource management.
1. Lots of work that would take lots of time. To my knowledge all fbdev developers work in there spare free time. No one does this for a living. So do most of the drm developers, I know I do and Jon Smirl does, and Eric Anholt does and I think us three have been the largest contributers apart from new driver submissions... 2. Sharing of headers. The dri headers are isolated in the drm directory. I totally understand why :-) It makes merging easier for them. The disadvantage is no one in the fbdev can use them easily :-( I plan to move them in 2.6.12 maybe .. it might be 2.6.13 by the time I get around to it, just some minor issues.. Arjan asked me for this ages ago as well... 3. DRM has way to much functionality for most embedded devices. I have talked to embedded guys before and they want a simple api to work with. By default DRM builds in everything. A simple api mean alot to those guys. Plus the extra built in code bloat takes up to much space which is precious on embedded devices. If a devices doesn't support dma then the dma code doesn't need to be built in. Well crap on that, the old DRM didn't build everything in people complained aw this code is too messy, build everything in, now you want to revert? damn you all!!! :-), I understand I'm just saying we can't have it both ways.. and too be honest I'm an embedded person and I just want it to work, with a Linux kernel you rarely get to an every byte counts embedded env, of if you are you aren't using the stock Linus kernel 4. Which comes to the next point. The code is not modular enough. Take drm_bufs.c. Everything is a ioctl function. This has a few disadvantages. One is the fbdev layer couldn't just link into it so fbcon could use it. The second is it's not easy to take advantage of things like sysfs. If you could untangle the code somewhat it would make life so much easier. That would include making life easier for OS ports. the reason we can't take advantage of sysfs or anything like it is that we can't bind to the PCI device as we break things.. this is the root of a lot of our problems... 5. The license issue. The DRI code is GPL and additional rights. What is that? Nope the drm code is BSD... there should be no GPL anywhere near it... it is GPL in the kernel as of course it is imported into a GPL work.. but the code is available for BSD uses Jon's last plan - was like to have a radeon basic module, with fb and drm personalities and in fact any number of personalities..taking radeon as example: base module : hotplug, reset, monitor probing, memory management, CP programming and locking. fb: adds accelerated fb functions using CP locking. drm: adds drm functionality on top of base module, drm ioctl interfaces etc.. I've looked at Alans ideas on a vga_class driver and have decided they are unworkable due to the massive initial changes they involve in *every* fb/drm driver in the kernel, I cannot undertake a work of that magnitude without fb people being involved and the chances of breaking a lot of stuff.. maybe a 2.7 thing but I don't think we'll ever have a 2.7 for this stuff... What I do think though is that ideas of a the vga class driver could be made into a helper module that the base graphics driver uses to do some standard things, like reset and stuff.. I'm hoping to get a better handle on these ideas and write something up.. but they are mostly Jons ideas better presented :-) Dave. --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: POSTing of video cards (WAS: Solo Xgl..)
On Mon, 2005-02-21 at 23:42 -0500, Jon Smirl wrote: On Tue, 22 Feb 2005 14:12:48 +1100, Benjamin Herrenschmidt [EMAIL PROTECTED] wrote: It's up to each driver to detect wether it's card need to be POSTed or not. Anything else would mean infinite breakage. Your approach is that it is a per driver problem. I was taking a different tack and looking at it as a BIOS deficiency that should be compensated for. There is already code in the kernel for identifying the boot video device. Your assumption is rather specific to a given platform... what if you have a card with no ROM (embedded system) but your kernel has a copy of what should be the ROM at hand ? (flash is expensive, heh :) I was working on the assumption that all PCI based, VGA class hardware that is not the boot device needs to be posted. That isn't the case on all platforms. Also, I like the flexibility of having a userland helper since that doesn't tie us to the semantics of an x86 platform BIOS (we could have an OF emulator too, or whatever binary program provided by the vendor in userspace to reinit the card without having to link that with the kernel). I think my approach is the most flexible in the long run. And that the posting should occur before the drivers are loaded. In order words the BIOS should have provided initialized hardware but since it didn't we can apply a fixup in the PCI driver. I also suspect there may be SCSI disk controller cards that need the same procedure. I don't think we have to do these assumptions. It should really be under driver control. I have no strong opinions on how to fix the post problem, I just want to make sure the problem is fully discussed by the relevant people and a consensus solution is achieved. I'm not sure that all of the core kernel developers that might be impacted by this have considered all of the options. I would like to try and get a consensus design and avoid reimplementing everything ten times. Agreed. Ben. --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: POSTing of video cards (WAS: Solo Xgl..)
On Mon, 2005-02-21 at 23:56 -0500, Alex Deucher wrote: another advantage of the emulator would be that PC vga cards could be used in non-x86 platforms, which I'm sure would be quite popular... That's implied indeed... though Jon approach would require the common code to know that we are on a platform that didn't run the x86 BIOS on this or this card... Some non-x86 platforms do already have an emulator in the firmware, some do POST all cards, some don't, it's really tricky to try to know from the generic code what to do here and will probably lead us into endless trouble. (We may want to avoid some cards, broken BIOSes, etc... and do it all by hand). I think that the driver is the chief here and the one to know what to do with the cards it drives. It can detect a non-POSTed card and deal with it. What we can/should provide, is a ncie helper to do the job once the driver decides to have a go at it. I think userspace is the right solution, similar to the firmware loader helpers, as I wrote earlier. There are a few issues related on trying to run these before / is mounted or during the sleep process, but those are things I plan to work on fix sooner or later. (Which is also why it has to be an asynchronous API, so that the helper can call back later when the helper has been found). Ben. --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] Resource management.
On Tue, 22 Feb 2005 15:46:03 +1100, Dave Airlie [EMAIL PROTECTED] wrote: 1. Lots of work that would take lots of time. To my knowledge all fbdev developers work in there spare free time. No one does this for a living. So do most of the drm developers, I know I do and Jon Smirl does, and Eric Anholt does and I think us three have been the largest contributers apart from new driver submissions... As far as I know none of the significant contributors on either fbdev or DRM are being paid to work on the project. 2. Sharing of headers. The dri headers are isolated in the drm directory. I totally understand why :-) It makes merging easier for them. The disadvantage is no one in the fbdev can use them easily :-( I plan to move them in 2.6.12 maybe .. it might be 2.6.13 by the time I get around to it, just some minor issues.. Arjan asked me for this ages ago as well... I'd like to take this further and move the stuff in drivers/video to drivers/video/fb and then move drm from drivers/char/drm to drivers/video/drm. I'd also like to consolidate drm and fbdev Kconfig menus. 3. DRM has way to much functionality for most embedded devices. I have talked to embedded guys before and they want a simple api to work with. By default DRM builds in everything. A simple api mean alot to those guys. Plus the extra built in code bloat takes up to much space which is precious on embedded devices. If a devices doesn't support dma then the dma code doesn't need to be built in. Well crap on that, the old DRM didn't build everything in people complained aw this code is too messy, build everything in, now you want to revert? damn you all!!! :-), I understand I'm just saying we can't have it both ways.. and too be honest I'm an embedded person and I just want it to work, with a Linux kernel you rarely get to an every byte counts embedded env, of if you are you aren't using the stock Linus kernel If you removed the EXPORT_SYMBOLs and compiled everything in, won't the compiler just eliminate the dead code for you? PCI Express is a big reason for the new core/personality split. There are Nforce4 motherboards now with 16 16x sockets. That means you can plug 16 different video cards in if you want. The days of a single AGP slot are over. If someone will send me one (with the four Opteron chips) I'll write drivers for it. 4. Which comes to the next point. The code is not modular enough. Take drm_bufs.c. Everything is a ioctl function. This has a few disadvantages. One is the fbdev layer couldn't just link into it so fbcon could use it. The second is it's not easy to take advantage of things like sysfs. If you could untangle the code somewhat it would make life so much easier. That would include making life easier for OS ports. the reason we can't take advantage of sysfs or anything like it is that we can't bind to the PCI device as we break things.. this is the root of a lot of our problems... This not binding to the PCI device has to be fixed. DRM can not support hotplug or suspend/resume without a device to bind to. Jon's last plan - was like to have a radeon basic module, with fb and drm personalities and in fact any number of personalities..taking radeon as example: base module : hotplug, reset, monitor probing, memory management, CP programming and locking. fb: adds accelerated fb functions using CP locking. drm: adds drm functionality on top of base module, drm ioctl interfaces etc.. I have already coded most of this up and it works for me. Unfortunately I derived it from the DRM codebase instead of the fbdev one. fbdev has changed too much in the last six months to allow a simple merge. Now I'm regenerating patches against fbdev using my prior code. A smaller step is to just treat radeonfb as the base module. This will eat up extra memory for x86 users and they will complain, but we can split it into three pieces later. I think good first step would simply be to get DRM and fbdev both into drivers/video and get the DRM h files into include/linux. I've looked at Alans ideas on a vga_class driver and have decided they are unworkable due to the massive initial changes they involve in *every* fb/drm driver in the kernel, I cannot undertake a work of that magnitude without fb people being involved and the chances of breaking a lot of stuff.. maybe a 2.7 thing but I don't think we'll ever have a 2.7 for this stuff... My head hurts thinking about how much editing this would involve. What I do think though is that ideas of a the vga class driver could be made into a helper module that the base graphics driver uses to do some standard things, like reset and stuff.. I'm hoping to get a better handle on these ideas and write something up.. but they are mostly Jons ideas better presented :-) Dave. -- Jon Smirl [EMAIL PROTECTED] --- SF email is
Re: [Linux-fbdev-devel] Resource management.
1. Lots of work that would take lots of time. To my knowledge all fbdev developers work in there spare free time. No one does this for a living. So do most of the drm developers, I know I do and Jon Smirl does, and Eric Anholt does and I think us three have been the largest contributers apart from new driver submissions... Ug :-( That is sad!!! 2. Sharing of headers. The dri headers are isolated in the drm directory. I totally understand why :-) It makes merging easier for them. The disadvantage is no one in the fbdev can use them easily :-( I plan to move them in 2.6.12 maybe .. it might be 2.6.13 by the time I get around to it, just some minor issues.. Arjan asked me for this ages ago as well... Okay. Where will they go? include/video ? 3. DRM has way to much functionality for most embedded devices. I have talked to embedded guys before and they want a simple api to work with. By default DRM builds in everything. A simple api mean alot to those guys. Plus the extra built in code bloat takes up to much space which is precious on embedded devices. If a devices doesn't support dma then the dma code doesn't need to be built in. Well crap on that, the old DRM didn't build everything in people complained aw this code is too messy, build everything in, now you want to revert? damn you all!!! :-), Ha Ha. I didn't know the history. I understand I'm just saying we can't have it both ways.. and too be honest I'm an embedded person and I just want it to work, with a Linux kernel you rarely get to an every byte counts embedded env, of if you are you aren't using the stock Linus kernel I can live with this issue as long it would not increase the complexity of framebuffer only devices. Simple api is very important to me. The current fbdev api is designed to be very simple for the most common cases. It can get complex tho with exotic hardware. 4. Which comes to the next point. The code is not modular enough. Take drm_bufs.c. Everything is a ioctl function. This has a few disadvantages. One is the fbdev layer couldn't just link into it so fbcon could use it. The second is it's not easy to take advantage of things like sysfs. If you could untangle the code somewhat it would make life so much easier. That would include making life easier for OS ports. the reason we can't take advantage of sysfs or anything like it is that we can't bind to the PCI device as we break things.. this is the root of a lot of our problems... Is this because you want to be OS portable? This makes things very very hard to merge. Fbdev attempts to take advantage the most powerful linux kernel features. 5. The license issue. The DRI code is GPL and additional rights. What is that? Nope the drm code is BSD... there should be no GPL anywhere near it... it is GPL in the kernel as of course it is imported into a GPL work.. but the code is available for BSD uses If it is GPL in the kernel then that is fine. We can work with that. I don't care about userland code. Jon's last plan - was like to have a radeon basic module, with fb and drm personalities and in fact any number of personalities..taking radeon as example: base module : hotplug, reset, monitor probing, memory management, CP programming and locking. fb: adds accelerated fb functions using CP locking. drm: adds drm functionality on top of base module, drm ioctl interfaces etc.. That will be a huge amount of work! BTW what does CP stand for? I've looked at Alans ideas on a vga_class driver and have decided they are unworkable due to the massive initial changes they involve in *every* fb/drm driver in the kernel, I cannot undertake a work of that magnitude without fb people being involved and the chances of breaking a lot of stuff.. maybe a 2.7 thing but I don't think we'll ever have a 2.7 for this stuff... What I do think though is that ideas of a the vga class driver could be made into a helper module that the base graphics driver uses to do some standard things, like reset and stuff.. I'm hoping to get a better handle on these ideas and write something up.. but they are mostly Jons ideas better presented :-) As for the VGA class driver. We already have something like that for the fbdev layer. Take a look at vgastate.c. It was written originally so you could go from vgacon to fbdev without fbcon and back to vgacon state again. It also has common functions for all the drivers to work with. I already asked Jon to merge his work with that code. That code could also be very useful for vgacon in the future. We need vga core management in the kernel. --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now.
Re: 32/64-bit ioctl compatibility
Dave Airlie writes: How it has to work, is taking a current DRI 32-bit binary, build a drm that should support 64-bits.. see does it work with the current 32-bit one... then write a Mesa patch that supports 64-bits and make it work on the drm you just made... also take a 64-bit pure drm and 64-bit pure DRI and make sure they work... That's what I want to achieve. Changing the drm and Mesa at once incompatibly isn't going to get past me, and I haven't proven that Egberts patch isn't backwards compat, but nobody has proven to me that it doesn't break anything, and as I have no access to any 64-bit hardware it is up to other people to convince me ... The hardest bit that I have seen so far is dealing with the offset and handle fields in the drm_map_t. I'll push on it a bit further then, if no-one else is hacking on this. Paul. --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] Resource management.
On Tue, 22 Feb 2005 05:13:07 + (GMT), James Simmons [EMAIL PROTECTED] wrote: 4. Which comes to the next point. The code is not modular enough. Take drm_bufs.c. Everything is a ioctl function. This has a few disadvantages. One is the fbdev layer couldn't just link into it so fbcon could use it. The second is it's not easy to take advantage of things like sysfs. If you could untangle the code somewhat it would make life so much easier. That would include making life easier for OS ports. the reason we can't take advantage of sysfs or anything like it is that we can't bind to the PCI device as we break things.. this is the root of a lot of our problems... Is this because you want to be OS portable? This makes things very very hard to merge. Fbdev attempts to take advantage the most powerful linux kernel features. My turn to laugh! It's because Linux only allow one driver to bind to the device and fbdev has already bound to it. We have done siginificant work to DRM to try and work around this (stealth mode) but the right solution is to have a common base driver. -- Jon Smirl [EMAIL PROTECTED] --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: POSTing of video cards (WAS: Solo Xgl..)
On Tue, 22 Feb 2005 16:13:36 +1100, Benjamin Herrenschmidt [EMAIL PROTECTED] wrote: On Mon, 2005-02-21 at 23:56 -0500, Alex Deucher wrote: I think that the driver is the chief here and the one to know what to do with the cards it drives. It can detect a non-POSTed card and deal with it. What about the x86 case of VGA devices that run without a driver being loaded? Do we force people to load an fbdev driver to get the reset? The BIOS deficiency strategy works for these devices. -- Jon Smirl [EMAIL PROTECTED] --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: POSTing of video cards (WAS: Solo Xgl..)
On Tue, 22 Feb 2005 16:13:36 +1100, Benjamin Herrenschmidt [EMAIL PROTECTED] wrote: What we can/should provide, is a ncie helper to do the job once the driver decides to have a go at it. I think userspace is the right solution, similar to the firmware loader helpers, as I wrote earlier. There are a few issues related on trying to run these before / is mounted or during the sleep process, but those are things I plan to work on fix sooner or later. (Which is also why it has to be an asynchronous API, so that the helper can call back later when the helper has been found). Can a userspace solution solve the problem of cards that need to be posted when they are coming out of suspend? -- Jon Smirl [EMAIL PROTECTED] --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: POSTing of video cards (WAS: Solo Xgl..)
On Tue, 2005-02-22 at 01:03 -0500, Jon Smirl wrote: On Tue, 22 Feb 2005 16:13:36 +1100, Benjamin Herrenschmidt [EMAIL PROTECTED] wrote: On Mon, 2005-02-21 at 23:56 -0500, Alex Deucher wrote: I think that the driver is the chief here and the one to know what to do with the cards it drives. It can detect a non-POSTed card and deal with it. What about the x86 case of VGA devices that run without a driver being loaded? Do we force people to load an fbdev driver to get the reset? The BIOS deficiency strategy works for these devices. Do we need to deal with those at all ? (I mean _really_: do we care ?) And even if we did, then we could have the vga legacy driver use the firmware loader to boot them. And again, you seem to dismiss all my other arguments... Ben. --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: POSTing of video cards (WAS: Solo Xgl..)
On Tue, 2005-02-22 at 01:05 -0500, Jon Smirl wrote: On Tue, 22 Feb 2005 16:13:36 +1100, Benjamin Herrenschmidt [EMAIL PROTECTED] wrote: What we can/should provide, is a ncie helper to do the job once the driver decides to have a go at it. I think userspace is the right solution, similar to the firmware loader helpers, as I wrote earlier. There are a few issues related on trying to run these before / is mounted or during the sleep process, but those are things I plan to work on fix sooner or later. (Which is also why it has to be an asynchronous API, so that the helper can call back later when the helper has been found). Can a userspace solution solve the problem of cards that need to be posted when they are coming out of suspend? Yes, though they'll come up a bit later than the rest of the world if the driver can't resume them itself (which is what should happen normally, running the BIOS on resume is a hack). Also, as I wrote earlier, what we care about now is the API in the form of a helper. It fits well to have that helper just do something similar to the firmware loader, running the stuff in userspace, but that isn't mandatory, we could change later to be in-kernel, partially, or even have a CONFIG option wether to have the emulator in kernel or not :) The driver doesn't have to care if we provide a suitable API. And userspace helper is a good enough implementation to start with. Ben. --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: POSTing of video cards (WAS: Solo Xgl..)
On Tue, 22 Feb 2005 17:32:40 +1100, Benjamin Herrenschmidt [EMAIL PROTECTED] wrote: And even if we did, then we could have the vga legacy driver use the firmware loader to boot them. And again, you seem to dismiss all my other arguments... I'm not dismissing them, I'm in agreement with with doing it in the drivers if we are sure we have thought through all of the different cases where we might need to post. -- Jon Smirl [EMAIL PROTECTED] --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: POSTing of video cards (WAS: Solo Xgl..)
Does the kernel need to keep a bit that says the device has been posted, don't do it again? Should removing/inserting a driver cause a repost? I was going to add bit in pci_dev that tracks the reset status so that it will persist across unloads. Do we have code to tell if hardware needs a reset without the tracking bit? On the x86 DRM will run without fbdev loaded. So DRM needs to also be able to do the post and well as fbdev. Or we can just leave the old drivers alone and only implement this in a merged fbdev/drm driver? When current X loads it's going to reset the cards again, that may stomp anything the driver has set up. -- Jon Smirl [EMAIL PROTECTED] --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: POSTing of video cards (WAS: Solo Xgl..)
On Tue, 2005-02-22 at 01:52 -0500, Jon Smirl wrote: Does the kernel need to keep a bit that says the device has been posted, don't do it again? No. The kernel have no idea about what POSTing means in fact. That is also driver specific. Should removing/inserting a driver cause a repost? The driver should be able to determine that looking at the state of the device. Things like vgacon may need some massaging, but that is not something we need to care too much about :) I was going to add bit in pci_dev that tracks the reset status so that it will persist across unloads. Do we have code to tell if hardware needs a reset without the tracking bit? That doesn't have room in pci_dev, that only concerns a minority of HW and I don't think we need to track it accross load/unload. On the x86 DRM will run without fbdev loaded. So DRM needs to also be able to do the post and well as fbdev. Or we can just leave the old drivers alone and only implement this in a merged fbdev/drm driver? I think we need _at_least_ to make a common stub driver for fbdev/drm, and if possible, only implement that in the merged driver when that happens. We are talking about the future here. Existing users already have X happily POST'ing their cards. When current X loads it's going to reset the cards again, that may stomp anything the driver has set up. Yes, and X need to be fixed for that, this is _WRONG_, one of the numerous x86-centric assumptions in X. Note that the fbdev driver is currently aware that anything can happen to the card when in KD_GRAPHICS mode (and thus, the driver loses ownership). I restore as much as I need hopefully when coming back. So we may end up having a non-issue there. Once we have an Xgl on top of mesa solo, the problem will not happen. Ben. --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
