Re: Replace nopfn by fault
Johannes Engel wrote: > Thomas Hellström wrote: >> Johannes, >> >> If the patch works, it looks correct to me. >> However, you need to make sure (using defines) that the code will >> compile also on kernels that don't have the .fault method. >> >> /Thomas > Hi Thomas, > > thanks for reviewing and suggesting. :) > I created a new variable DRM_HAS_FAULT which is defined for kernels from > 2.6.23 and decides about using .fault or .nopfn. > I attach a corrected version. Wow, there are a lot ifdefs in the code. You could remove most of them if you do something like: #if (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,23)) #define DRM_HAS_FAULT #define DRM_FAULT_SIGBUS VM_FAULT_SIGBUS #else #define DRM_FAULT_SIGBUS NOPFN_SIGBUS #endif and then use DRM_FAULT_SIGBUS in the code below. Also, why don't you take these two ifdefs together? +#ifdef DRM_HAS_FAULT + unsigned long address = (unsigned long)vmf->virtual_address; +#endif int err; unsigned long bus_base; unsigned long bus_offset; unsigned long bus_size; +#ifdef DRM_HAS_FAULT + int ret = VM_FAULT_NOPAGE; +#else unsigned long ret = NOPFN_REFAULT; +#endif tom - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm-gem not working on 965 Was: Re: drm-gem libdrm automake fix
Steven J Newbury wrote: > On Wed, 2008-06-25 at 21:14 +0100, Steven J Newbury wrote: >> On Wed, 2008-06-25 at 20:03 +0100, Steven J Newbury wrote: >>> On Wed, 2008-06-25 at 11:30 -0700, Jesse Barnes wrote: On Wednesday, June 25, 2008 10:28 am Steven J Newbury wrote: > On Wed, 2008-06-25 at 16:29 +0100, Johannes Engel wrote: >> Steven J Newbury wrote: >>> When building with a separate objdir -I$(top_srcdir)/libdrm needs to be >>> added to the intel Makefile.am otherwise only $(top_builddir)/libdrm is >>> included which doesn't contain the source headers. >>> >>> I've also been unable to build the drm-gem DRM module against the >>> current git linux tree, what changes are needed (to the linux headers; >>> and symbol exports?) and is there a patch? >> Have a look at bug #16474. Also you need to export symbols shmem_getpage >> and shmem_file_setup via EXPORT_SYMBOL in /mm/shmem.c. >> For me it compiles using this changes but does not work stable since it >> crashes once you start for example glxgears. >> >> Cheers, Johannes > Thanks Johannes, I spotted that soon after posting (I filter the > bugzilla messages separately) and have just tried it. Unfortunately, I > don't even get that far, drm reports that it "fails to map the ring > buffer" and X fails to start. :( Are you running the drm-gem branch of the 2D driver as well? >>> It certainly should have been! :) >>> >>> I'll give it another try tomorrow. > OK. I tried i again. I get the following oops in my kernel log: > > Jun 26 03:23:32 infinity [drm:i915_gem_init_ringbuffer] *ERROR* Failed > to map ringbuffer. > Jun 26 03:23:32 infinity [ cut here ] > Jun 26 03:23:32 infinity kernel BUG > at > /var/tmp/portage/x11-base/x11-drm-/work/drm/linux-core/drm_gem.c:378! > Jun 26 03:23:32 infinity invalid opcode: [1] PREEMPT SMP > Jun 26 03:23:32 infinity CPU 0 > Jun 26 03:23:32 infinity Modules linked in: snd_pcm_oss snd_mixer_oss > snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device fuse bridge llc > bnep rfcomm l2cap cpufreq_ondemand acpi_cpufreq coretemp smsc47m192 > hwmon_vid i915 drm tpm_tis tpm tpm_bios rfkill hci_usb bluetooth arc4 > ecb pcmcia firewire_ohci firewire_core crc_itu_t snd_hda_intel iwl3945 > mac80211 led_class snd_pcm snd_timer yenta_socket rsrc_nonstatic > pcmcia_core snd_page_alloc pcspkr cfg80211 tg3 snd_hwdep snd soundcore > joydev [last unloaded: microcode] > Jun 26 03:23:32 infinity Pid: 4369, comm: X Not tainted > 2.6.26-rc8-00010-g0233dfa #18 > Jun 26 03:23:32 infinity RIP: 0010:[] > [] :drm:drm_gem_object_free+0x13/0x52 > Jun 26 03:23:32 infinity RSP: 0018:810077c4dbf8 EFLAGS: 00010246 > Jun 26 03:23:32 infinity RAX: 0001 RBX: 81007c053000 > RCX: > Jun 26 03:23:32 infinity RDX: RSI: 0040 > RDI: 810072cbb240 > Jun 26 03:23:32 infinity RBP: 810072cbb240 R08: 806fefc0 > R09: 810001016f98 > Jun 26 03:23:32 infinity R10: 0008ef78621b R11: 0046 > R12: 81007c055000 > Jun 26 03:23:32 infinity R13: 81007c053000 R14: ffea > R15: 810079c168a0 > Jun 26 03:23:32 infinity FS: 7fd0de851740() > GS:80747000() knlGS: > Jun 26 03:23:32 infinity CS: 0010 DS: ES: CR0: > 80050033 > Jun 26 03:23:32 infinity CR2: 004c7010 CR3: 77c1f000 > CR4: 06e0 > Jun 26 03:23:32 infinity DR0: DR1: > DR2: > Jun 26 03:23:32 infinity DR3: DR6: 0ff0 > DR7: 0400 > Jun 26 03:23:32 infinity Process X (pid: 4369, threadinfo > 810077c4c000, task 81007d83ad80) > Jun 26 03:23:32 infinity Stack: 0002 810072cbb240 > a0172027 803d505d > Jun 26 03:23:32 infinity 81007c053000 81007c055000 > 810072cbb240 a01907b1 > Jun 26 03:23:32 infinity 8100795879d0 a0198cf8 > 6459 a0190679 > Jun 26 03:23:32 infinity Call Trace: > Jun 26 03:23:32 infinity [] ? :drm:drm_gem_object_free > +0x0/0x52 > Jun 26 03:23:32 infinity [] ? kref_put+0x41/0x4c > Jun 26 03:23:32 infinity > [] ? :i915:i915_gem_entervt_ioctl+0x138/0x251 > Jun 26 03:23:32 infinity > [] ? :i915:i915_gem_entervt_ioctl+0x0/0x251 > Jun 26 03:23:32 infinity [] ? :drm:drm_unlocked_ioctl > +0x19b/0x213 > Jun 26 03:23:32 infinity [] ? xfs_iunlock+0x1d/0x7c > Jun 26 03:23:32 infinity [] ? xfs_write+0x6cd/0x6e8 > Jun 26 03:23:32 infinity [] ? handle_mm_fault > +0x39c/0x759 > Jun 26 03:23:32 infinity [] ? do_sync_write+0xce/0x113 > Jun 26 03:23:32 infinity [] ? getnstimeofday+0x38/0x92 > Jun 26 03:23:32 infinity [] ? do_page_fault > +0x47e/0x832 > Jun 26 03:23:32 infinity [] ? ktime_get_ts+0x21/0x4a > Jun 26 03:23:32 infinity [] ? ktime_get+0xc/0x41 > Jun 26 03:23:32 infinity [] ? hrtick_start_fair > +0x11a/0x164 > Jun 26 03:23:32
Re: DRM development process wiki page..
Keith Whitwell wrote: >> Major bumps once stuff went into the kernel weren't allowed at all. >> You'd need to fork the driver in any case. So we did this once or >> twice on drivers in devel trees like mach64. >> However upstream first policy should avoid this need. I'd also prefer >> to see getparam for new features instead of version checks. The linear >> version check sucks. > > This is an interesting concept that opens up some ideas for dealing > with feature deprecation, etc. > > Think about opengl's extension mechanism -- features can be exposed > through that mechanism without ever providing a guarantee of future > availability -- in fact there is no guarantee of any availability > outside the current session. Future versions of a GL driver might add > or remove extensions as desired, within the constraints of the GL > version number advertised. Would you want to have the ioctl numbers dynamically allocated, like the event and error bases in the xserver? Otherwise you could run out of them if you statically allocate numbers for extensions which are then later removed. Or would you rather create a single entry point for the extension commands and the multiplex everything through that? Also, you'll have to distinguish between extensions supported by the kernel and userspace (like GLX server and client side extensions), and provide drm_get_proc_address() to get the userspace library entry points. I think the extension mechanism that OpenGL/GLX uses is much better then simple linear versioning. If the userspace code is properly written, you can deprecate and remove extensions without breaking anything (at worst the driver will simply refuse to work, but no crashes etc). No more 5 years waiting to remove old features - take that Linus! :) tom - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Patch for testing irq spinning
On 12/04/2008 05:16 AM, Keith Packard wrote: > On Thu, 2008-12-04 at 02:44 +0100, Pierre Willenbrock wrote: > >> Not looping in the irq-handler seems to work (so far, at least). > > Excellent. Looping should only be required when using MSI. Let's try to > get a few more people to report back before we claim 'success' here > though; the disadvantage of not looping is that we may lockup due to > missing an interrupt. We've only seen missing interrupts in MSI mode. Should I apply both patches or only the second one (the one that adds the 'break;')? I applied both and I was still getting the IRQ storms. This is also on a GM965. tom - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Patch for testing irq spinning
On 12/05/2008 01:54 AM, Keith Packard wrote: > On Thu, 2008-12-04 at 15:43 +0100, Tomas Carnecky wrote: > >> Should I apply both patches or only the second one (the one that adds >> the 'break;')? I applied both and I was still getting the IRQ storms. >> This is also on a GM965. > > It shouldn't have mattered. At this point, I'm curious if we're running > into trouble because of interrupt sharing. We've had good reports from > people using MSI on GM965, notwithstanding the errata which says they're > unreliable. It may be that our driver/linux uses them differently enough > that they work fine. Here's a patch which re-enables MSI for 965GM. Use > this in place of the other two patches and let us know if it works. In > other words, revert back to anholt/for-airlied and apply this patch: The irq storms seem to be gone. But I'm not sure if MSI is really usable. When I let glxgears run, it freezes after a ~10-30 seconds, and resumes normally after I move a window (doesn't have to be the glxgears window, just one window on the desktop). Is that maybe a symptom of the lost interrupts that the errata refers to (GM965 + MSI)? > > diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c > index ba89b42..553dd4b 100644 > --- a/drivers/gpu/drm/i915/i915_dma.c > +++ b/drivers/gpu/drm/i915/i915_dma.c > @@ -847,9 +847,10 @@ int i915_driver_load(struct drm_device *dev, unsigned > long > flags) >* and the registers being closely associated. >* >* According to chipset errata, on the 965GM, MSI interrupts may > - * be lost or delayed > + * be lost or delayed, but we use them anyways to avoid > + * stuck interrupts on some machines. >*/ > - if (!IS_I945G(dev)&& !IS_I945GM(dev)&& !IS_I965GM(dev)) > + if (!IS_I945G(dev)&& !IS_I945GM(dev)) > pci_enable_msi(dev->pdev); > > intel_opregion_init(dev); > -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: unable to build i915.ko
On 01/09/2009 01:31 PM, Abraham Varricatt wrote: > Hi guys, > > I recently obtained source of the DRM package from, > > git://git.freedesktop.org/git/mesa/drm > > I move to the drm directory on my system and run the following commands, > > ./autogen --prefix=$HOME/install > > make > > make –C linux-core > > This builds 13 modules. But the i915.ko is NOT being complied!! On the > good side, drm.ko is getting created. > > I use the “-C” so that it builds the modules for the current kernel. I’m > running on Ubuntu8.10 (kernel 2.6.27-7-generic) The chipset I have is an > Intel Q965. > > Anyone have any ideas on how I can get i915.ko to be built? The kernel modules are now being developed entirely within the kernel. Get the kernel source and build the drm module from there. tom -- Check out the new SourceForge.net Marketplace. It is the best place to buy or sell services for just about anything Open Source. http://p.sf.net/sfu/Xq1LFB -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: unable to build i915.ko
On 01/09/2009 04:50 PM, Sergio Monteiro Basto wrote: > On Fri, 2009-01-09 at 14:04 +0100, Tomas Carnecky wrote: >> The kernel modules are now being developed entirely within the >> kernel. >> Get the kernel source and build the drm module from there. > > Can I build just the drm modules ? > if yes how I do it ? configure the kernel as usual (make menuconfig|gconfig) and then: $ make drivers/gpu/drm But you really should update your kernel and modules at the same time. Especially now that so many things around the kernel modules change. tom -- Check out the new SourceForge.net Marketplace. It is the best place to buy or sell services for just about anything Open Source. http://p.sf.net/sfu/Xq1LFB -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Deleting old branches
On 01/09/2009 06:32 PM, Jesse Barnes wrote: > Oh, don't use the modesetting-gem branch anymore. The master branch of the > drm tree has all the libdrm bits you need, and Linus' git tree has the kernel > mode setting bits you need (even better would be to use Eric's tree, it has a > few fixes destined for Linus: > git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel drm-intel-next > branch). Many of the fdo and kernel.org trees have such old branches. In git these are basically throwaway branches where features are developed. But once the branches are merged into master, they have no reason to exist anymore. Having them there just confuses people. Would you consider deleting some of the old branches? For example, of the 70 branches in xf86-video-intel, 27 have already been merged with master (git branch -r --merged origin/master). tom -- Check out the new SourceForge.net Marketplace. It is the best place to buy or sell services for just about anything Open Source. http://p.sf.net/sfu/Xq1LFB -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Combining Mesa3D and DRI mailing lists and/or sites?
Keith Whitwell wrote: > The DRI list has in effect become the list for development of the drm > kernel module, libdrm, and the various memory manager implementations. > While Mesa is an important client of these, it is far from being the > only client. Interesting. Who else is a client of drm? (apart of the ATI driver which, last I heard, uses drm). tom - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
GEM/TTM interfaces
I have read (don't remember where) that once the kernel has a sensible infrastructure for file descriptors you'd want to convert all the ioctl code in GEM/TTM to standard syscalls. Is that true? Do you already know which syscalls would replace for example drmBOCreate() or the GEM_CREATE ioctl? Both functions create a new handle, so open(2) would be a candidate, but both functions also take a 'size' argument, which open doesn't support, so you'd still have to implement an fcntl/ioctl interface for such things. But I'm not a kernel guru so there might be a better syscall then open. On a related note, are there plans to merge the TTM and GEM APIs (the stuff that can be shared between the two)? From what I read in the vivid discussions here and on other mailing lists it doesn't seem that there is a clear winner. Also, for different situations different implementations might be required. So keeping both, at least for the time being, seems the way to go. But it's currently quite cumbersome to test both APIs, because you have to switch between the branches. Why not create an common interface that both TTM and GEM could implement and extend upon? Something like libdrm/dri_bufmgr.h in the drm-gem branch which I think tries to achieve this. This would allow you to have both memory managers in the same tree, and yet not interfere with each other. This would be to great advantage to users willing to test your code and also allow easy extensibility in case a third, even better, memory manager evolves in the future. However, in the dri_bufmgr interface I don't see any way to have the userspace check which memory manager the kernel module supports - which I think is important if the two memory managers are to live in the codebase at the same time. In my local tree I have added the basics of such interface. It basically allows the userspace query which MM the kernel module supports, and then based on that load the correct userspace counterpart. Would you be interested in such code? cheers tom - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
DRM() macro
Why are the DRM() macros used in the linux kernel drivers? I'm sure this has been discussed many times, but I can't find anything about it. Any explanations or pointers to webpages (archives) where it's explained are welcome. Thanks -- wereHamster a.k.a. Tom Carnecky Emmen, Switzerland (GC 3.1) GIT d+ s+: a--- C++ UL++ P L++ E- W++ N++ !o !K w ?O ?M ?V PS PE ?Y PGP t ?5 X R- tv b+ ?DI D+ G++ e-- h! !r !y+ --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM() macro
Ian Romanick wrote: Tomas Carnecky wrote: Why are the DRM() macros used in the linux kernel drivers? I'm sure this has been discussed many times, but I can't find anything about it. Any explanations or pointers to webpages (archives) where it's explained are welcome. Each DRM driver contains a slightly customized copy of some functions. The customzations are based on driver-specific #defines. The DRM macro is used to convert the generic name (i.e., addmap) to a device-specific name (i.e., radeon_addmap). This also makes it so that you can load multiple DRM modules into your kernel at once. If every DRM module had a function called addmap, you could only have one at a time. Thanks... but I personally prefer the fbdev approach. The fbdev core calls the appropriate functions (stored in a structure which is filled by the device drivers). Another question.. what interface do the drivers present to the userspace. Is it only the ioctl interface defined in drm.h or do the device specific drivers have their own ioctl additions? -- wereHamster a.k.a. Tom Carnecky Emmen, Switzerland (GC 3.1) GIT d+ s+: a--- C++ UL++ P L++ E- W++ N++ !o !K w ?O ?M ?V PS PE ?Y PGP t ?5 X R- tv b+ ?DI D+ G++ e-- h! !r !y+ --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
drawable & contexts
As it seems, there is the required code for managment of drawables within the drivers, but noone seems to use it (drm_drawable.h). Any reason for that? (I mean for not using it). -- wereHamster a.k.a. Tom Carnecky Emmen, Switzerland (GC 3.1) GIT d+ s+: a--- C++ UL++ P L++ E- W++ N++ !o !K w ?O ?M ?V PS PE ?Y PGP t ?5 X R- tv b+ ?DI D+ G++ e-- h! !r !y+ --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
device drivers (in general)
The dri/drm interface seems to be quite low-level. I heard somewhere that different devices have quite different registers and work in a quite different way. If it is true that it would be better to make a more high-level interface where every driver can do it's stuff as it needs. How much low/high-level should the interface be so you get the best performance out of these many different devices and don't have to make workarounds in the drivers. I have the impression that the newest cards have quite high-level chips interfaces (supporting shaders etc.). -- wereHamster a.k.a. Tom Carnecky Emmen, Switzerland (GC 3.1) GIT d+ s+: a--- C++ UL++ P L++ E- W++ N++ !o !K w ?O ?M ?V PS PE ?Y PGP t ?5 X R- tv b+ ?DI D+ G++ e-- h! !r !y+ --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: device drivers (in general)
Ian Romanick wrote: Tomas Carnecky wrote: The dri/drm interface seems to be quite low-level. I heard somewhere that different devices have quite different registers and work in a quite different way. If it is true that it would be better to make a more high-level interface where every driver can do it's stuff as it needs. How much low/high-level should the interface be so you get the best performance out of these many different devices and don't have to make workarounds in the drivers. I have the impression that the newest cards have quite high-level chips interfaces (supporting shaders etc.). The design priciple of the open-source drivers is that the kernel part acts as nothing more than a conduit to shove bits into the chip. It's the first time I hear that. Because of that, the interface is pretty raw and varies from chip to chip. For DMA programmed chips, the user-mode driver works by filling buffers with "stuff" and asking the kernel to kick of a DMA operation with the buffer. That's why so much of the ioctl inferface is device-dependent. This doesn't make for "workarounds in the drivers", it just means that the user-mode is written to work with its own low-level kernel-mode interface. This reminds me to XFree86. XFree86 requires root rights to run, because it accesses the hardware directly (using /dev/mem) and does other dangerous things. I think that the device driver should avoid that and expose a nice and safe interface to the userspace. On advantage of this is that we don't have to modify the kernel drivers very often. Some of the drivers have had regular updates to the user-mode part, but thier kernel driver hasn't been modified in over a year. For us, that's a *big* advantage. This is certainly a very unimportant thing (for me). Because all other parts of the kernel change regularly, why should the graphics drivers not? A device driver is not just a wrapper around the device which gives you access to the registers. Even the core components of your computer have a nice interface (your harddisk controller: open/read/write/close etc). The device driver should expose an interface, which can be used by all users[1] in a safe way. With the current design, you can't render into a off-screen buffer easily. Either you use X or DirectFB. But it's not possible to use it in a easy and safe way[2]. [1]: even /dev/hda or /dev/sda is readable by world (at least on my box). [2]: X isn't easy and DirectFB.. it's a bit better to use but it's still a lot of unnecessary code around the actual driver. -- wereHamster a.k.a. Tom Carnecky Emmen, Switzerland (GC 3.1) GIT d+ s+: a--- C++ UL++ P L++ E- W++ N++ !o !K w ?O ?M ?V PS PE ?Y PGP t ?5 X R- tv b+ ?DI D+ G++ e-- h! !r !y+ --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: device drivers (in general)
David Bronaugh wrote: A device driver is not just a wrapper around the device which gives you access to the registers. Even the core components of your computer have a nice interface (your harddisk controller: open/read/write/close etc). You're speaking of a generic interface to the hardware. The problem (from what I have seen) with doing this with 3D graphics hardware is that it really -is- all different. Different in design. You -could- put a whole OpenGL driver in the kernel, and that would abstract the hardware successfully, but there are a -LOT- of good arguments against this (bloating the kernel's image size by 2-3 megs would probably not be appreciated -- a LOT of bugs would get in, etc.) You're right, I had the opengl interface in my mind, but I certainly don't want to put it into the kernel. It's good to separate userspace and kernelspace. Another option would be to design a generic, more low-level wrapper for graphics hardware. In my opinion this is a huge undertaking (ever read chip docs? You try integrating 3000 pages of information (that would be around 5 different chips)). However, if you think this is a good idea, feel free to do it. Just take about 6 months off from life... That's why I think there should be a more high-level interface. My idea is that every card creates a device node in /dev which can be openend by anyone with appropriate rights. With each device is a userspace library associated which has implemented the interface functions (gl*). The interface between userspace library and device node is not defined, each driver/library pair can create's own interface. So it is possible to 1) implement everything in userspace and use the device driver only to access the framebuffer or 2) use hardware acceleration using the device driver. So it's possible that every driver developer can decide for himself what to put into the userspace library and what into the kernel driver. The only interface that is defined is opengl. (Actually, that's not just an idea, but my project. I've done quite a lot of work so far, now I'm looking for some opengl implementations I could use.) [1]: even /dev/hda or /dev/sda is readable by world (at least on my box). Which is fundamentally insecure. People can find your /etc/shadow file on /dev/hda or whatever and run John the Ripper or its ilk on it. Simple matter of using 'grep'. Ahem.. sorry.. I mean readable by anyone who can log into the machine, not many people in my case. And I'm thinking of usual home computers, not servers. (High performance graphics cards on servers?) [2]: X isn't easy and DirectFB.. it's a bit better to use but it's still a lot of unnecessary code around the actual driver. Unneccesary in -your- opinion. How much have you studied it? Just to render a nice picture using opengl (off-screen)? David "I am not a DRI developer" Bronaugh -- wereHamster a.k.a. Tom Carnecky Emmen, Switzerland (GC 3.1) GIT d+ s+: a--- C++ UL++ P L++ E- W++ N++ !o !K w ?O ?M ?V PS PE ?Y PGP t ?5 X R- tv b+ ?DI D+ G++ e-- h! !r !y+ --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: device drivers (in general)
David Bronaugh wrote: Tomas Carnecky wrote: David Bronaugh wrote: Another option would be to design a generic, more low-level wrapper for graphics hardware. In my opinion this is a huge undertaking (ever read chip docs? You try integrating 3000 pages of information (that would be around 5 different chips)). However, if you think this is a good idea, feel free to do it. Just take about 6 months off from life... That's why I think there should be a more high-level interface. My idea is that every card creates a device node in /dev which can be openend by anyone with appropriate rights. With each device is a userspace library associated which has implemented the interface functions (gl*). The interface between userspace library and device node is not defined, each driver/library pair can create's own interface. So it is possible to 1) implement everything in userspace and use the device driver only to access the framebuffer or 2) use hardware acceleration using the device driver. So it's possible that every driver developer can decide for himself what to put into the userspace library and what into the kernel driver. The only interface that is defined is opengl. Essentially, this is what the Mesa/DRI/DRM combo do now (as I understand it; feel free to correct me). Each slash in 'Mesa/DRI/DRM' stands for an interface, which is more or less predefined (for example drm_*.h in drivers/char/drm). Why not 'OpenGL/Hardware'? -- wereHamster a.k.a. Tom Carnecky Emmen, Switzerland (GC 3.1) GIT d+ s+: a--- C++ UL++ P L++ E- W++ N++ !o !K w ?O ?M ?V PS PE ?Y PGP t ?5 X R- tv b+ ?DI D+ G++ e-- h! !r !y+ --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: device drivers (in general)
Mike Mestnik wrote: I think every thing Tomas Carnecky has said here about device driver design is valid and dose apply to the DRM/dri. He may not know every thing about system security, but we also all have our strangths and his strangth is oviously device design. One way of interpeting what he is trying to say is that the DRM should be even lower-level and get back to the basics. There are going tobe alot of gripes and grones, but it's UNIX not windows. ioctl ONLY for registers, even mmaped ones. read/write for DMA. seek for changing where your DMAing or writing to the GART and video mem. select sleeping and waiting. There is no versioning, invalid ioctls will be enuff to find out it's not supported by the card or driver. To identify the modual /proc/devices major number lookups. For security using diffrent minor numbers, 0 for mode setting, 1 for 2d, 2 for 3d, ext. Where 2 has the same modes as /dev/mem and games/users have to be setuid root they do directly access the hardware. The idea is to reduce the kernel mod to nothing more then device enumeration and detection. However you solve it.. I don't care about how the kernel driver <--> userspace driver interface is defined or implemented. I just don't think there should be one interface for all devices, as it is now with DRM. The userspace dri driver is the only user of these kernel drivers. As each device works differently, why don't adapt this interface to each device. With the current design, there are three interfaces: dri (in userspace), drm (between kernel and userspace) and Mesa (opengl). Why don't define only on interface (opengl) so each driver can be optimized as much as possible. Then make packages with kernel driver/userspace driver pairs for each card that can be compiled separately (without any other prerequisites). -- wereHamster a.k.a. Tom Carnecky Emmen, Switzerland (GC 3.1) GIT d+ s+: a--- C++ UL++ P L++ E- W++ N++ !o !K w ?O ?M ?V PS PE ?Y PGP t ?5 X R- tv b+ ?DI D+ G++ e-- h! !r !y+ --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: device drivers (in general)
Michel DÃnzer wrote: The userspace dri driver is the only user of these kernel drivers. No, there's also the DDX drivers, XvMC, ... and there could be more in the future. So you tell me that there are at least three (DRI/DDX/XvMC) libraries which do basically the same thing? If, and that's what someone wrote here, the DRM kernel drivers are 'nothing more than a conduit to shove bits into the chip', then these three userspace libraries duplicate (more or less) the same code. Or did I understand something wrong? -- wereHamster a.k.a. Tom Carnecky Emmen, Switzerland (GC 3.1) GIT d+ s+: a--- C++ UL++ P L++ E- W++ N++ !o !K w ?O ?M ?V PS PE ?Y PGP t ?5 X R- tv b+ ?DI D+ G++ e-- h! !r !y+ --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id149&alloc_id66&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Kernel thoughts of a Linux user
Helge Hafting wrote: From the [ruby patch] documentation: The main problem up to this date (November 2004) is that linux kernel has only one behaviour regarding multiple keyboards : any key pressed catched on any keyboard is redirected to the one and only active Virtual Terminal (VT). Will this be changed/improved when the console code is moved into userspace, like some have proposed? I don't know about any userspace console, but the ruby patch lets you have several independent active VTs at the same time. So the above mentioned problem is solved - they keyboards does not interfere with each other. I think the it would be much nicer to habe the console code in userspace, ruby is only a patch, not in the mainline kernel, and AFAIK not even in any experimental (-mm/-ac/-etc) tree. There are many aproaches how to solve the problem of having more than one ative VT, and the userspace console seems to be the nicest one. I know that Jon Smirl wrote an email some time ago, here it is: http://lkml.org/lkml/2004/8/2/111, look at point 15. I like the idea and I've written him several times, but he didn't answer :( Anyone knows what's happened with him? I know he's involved in the DRM development, so I CC to the dri-devel list. I'd really like to help with this, as I like and share his ideas. Is anyone already working on this? I mean pulling the console code out of the kernel into the userspace. tom --- 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://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
DRI and framebuffer
Hi, Can I control a graphics card _completely_ with DRI? I mean allocate the framebuffer, switch between modes etc. Or do I need some kind of helper code that does these things (like fbdev or the Xserver)? I'm particulary interested in allocating memory for the framebuffer via DRI, I think there is an ioctl for that, but I'm not sure. And is it possible to allocate offscreen memory with DRI? So I could render into it, read the pixels out of it and put them into an image (for example). thanks tom --- 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://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRI and framebuffer
Tomas Carnecky wrote:
Hi,
Can I control a graphics card _completely_ with DRI? I mean
allocate the framebuffer, switch between modes etc. Or do I
need some kind of helper code that does these things (like
fbdev or the Xserver)?
I'm particulary interested in allocating memory for the
framebuffer via DRI, I think there is an ioctl for that, but
I'm not sure.
And is it possible to allocate offscreen memory with DRI?
So I could render into it, read the pixels out of it and
put them into an image (for example).
I've checked out the cvs drm and mesa tree and did a bit of browsing..
In the mesa tree under src/mesa/drivers/dri/*/xxx_context.c, there
usually is xxxMakeCurrent, xxxCreateContext, xxxDestroyContext, but no
xxxCreateFramebuffer. It seems that the framebuffer is allocated
somewhere else, not in the dri code.
Then I found this nice file in the drm tree: linux-core/drm_drawable.c
But it's almost empty, only two noop functions. What are they for?
Are they used somewhere? Is DRM_IOCTL_ADD_DRAW used?
It seems to me that the framebuffer is allocated from the main meory,
not from the videocard memory.
Ok, I think I've found it: linux-code/drm_bufs.c::drm_addmap (or
DRM_IOCTL_ADD_MAP).
typedef struct drm_map {
unsigned long offset;/**< Requested physical address (0 for SAREA)*/
unsigned long size; /**< Requested physical size (bytes) */
drm_map_type_t type; /**< Type of memory to map */
drm_map_flags_t flags; /**< Flags */
void *handle;/**< User-space: "Handle" to pass to mmap() */
/**< Kernel-space: kernel-virtual address */
int mtrr;/**< MTRR slot used */
/* Private data */
} drm_map_t;
How can the userspace know which offset is free? Or is it possible to
map two overlapping areas? In drm_bufs.c::drm_addmap is:
case _DRM_AGP:
if (drm_core_has_AGP(dev)) {
map->offset += dev->agp->base;
map->mtrr = dev->agp->agp_mtrr; /* for getmap */
}
It just returns the offset plus the start of the agp memory, but no
checks for overlapping maps, so is it possible to do the following?
drm_addmap(type = _DRM_AGP, offset = 0, size = 100)
drm_addmap(type = _DRM_AGP, offset = 10, size = 90)
Does the agp memory have some size restrictions? Or can I map any size?
drm_addmap(type = _DRM_AGP, offset = 0, size = MAX_INT)?
thanks
tom
---
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://productguide.itmanagersjournal.com/
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRI and framebuffer
Felix Kühling wrote:
Am Sa, den 18.12.2004 schrieb Tomas Carnecky um 14:54:
Most (all?) supported hardware doesn't support multiple clipping
rectangles in hardware, so the driver iterates over them and draws all
primitives once in each clipping rectangle.
Quite CPU expensive, isn't it?
It seems to me that the framebuffer is allocated from the main meory,
not from the videocard memory.
Ok, I think I've found it: linux-code/drm_bufs.c::drm_addmap (or
DRM_IOCTL_ADD_MAP).
typedef struct drm_map {
unsigned long offset;/**< Requested physical address (0 for SAREA)*/
unsigned long size; /**< Requested physical size (bytes) */
drm_map_type_t type; /**< Type of memory to map */
drm_map_flags_t flags; /**< Flags */
void *handle;/**< User-space: "Handle" to pass to mmap() */
/**< Kernel-space: kernel-virtual address */
int mtrr;/**< MTRR slot used */
/* Private data */
} drm_map_t;
DRM maps are created by the Xserver (2D driver) in order to make certain
address ranges available to DRM clients (3D driver). This way
front/back/depth buffers, DMA buffers, texture regions, sometimes MMIO
regions and the shared memory area that contains the global DRM lock are
handled. DRM clients can map these into their address space using the
drm_map ioctl.
Who exactly does map the memory? The Xserver or the DRM library? If it's
the Xserver, how can it know where all the different buffers are?
tom
---
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://productguide.itmanagersjournal.com/
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRI and framebuffer
Felix Kühling wrote: Am So, den 19.12.2004 schrieb Tomas Carnecky um 15:32: Who exactly does map the memory? The Xserver or the DRM library? If it's the Xserver, how can it know where all the different buffers are? I'm not sure I understand the question. I'll rephrase the above and hope it clears up any misunderstandings. The Xserver creates the maps using the drm_addmap ioctl. It knows the physical location of the video memory from the the PCI resource lists (you may want to take a look at the PCI scan in your Xorg.0.log for details). As for AGP memory, it only needs to pass offsets in the AGP aperture. Shared memory areas (only the Sarea in most/all drivers) are allocated at free physical addresses. They don't even need to be physically contiguous. These drm maps are mapped by the 3D driver into the direct rendering application's address space using the drm_map ioctl. So.. the Xserver creates the maps, and the 3D driver maps them into the application's address space? Because the maps are identified using 'handles', the Xserver has to pass the handles to the 3D driver, right? And does the Xserver map the whole video memory (everything it sees in the PCI resource list) or just what it needs? There is the DRI kernel module for each card/chip, the PCI scaning could be done in this kernel module. tom --- 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://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
