[Dri-devel] HEADSUP: DRM probe changes
I realize I should have sent this out earlier, but on Thursday I committed a change to the manner that DRM devices are probed. Ideally it won't have any effect on people, but there may have been problems. Basically, the DRM only attaches now when it finds a device ID it knows of. I think the PCI ID lists are complete, but there may be issues. If you have problems with getting the DRM to attach after 2003/10/16, please email me with what hardware you have and the output of scanpci. Note that there was a bug that would prevent probing of devices on 2.5+ linux kernels up until 2003/10/19 (yesterday). This is a step in the process of making the DRM attach to a specific device. It'll help with the standalone DRI, and also with making the DRM a proper FreeBSD driver. -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] --- This SF.net email is sponsored by OSDN developer relations Here's your chance to show off your extensive product knowledge We want to know what you know. Tell us and you have a chance to win $100 http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mga anisotropic filtering
On Mon, 2003-10-20 at 14:52, Jon Smirl wrote: Eric Anholt is in the middle of doing a generic fix for this problem. See the Adding hardware detection to DRI drivers thread. The current DRM drivers now do PCI ID detection on both Linux and BSD. He is also adding an enum for chip family but I'm not sure what the status is. There is supposed to be a new DRM IOCTL for getting PCI ID and family. The device private info associated with chipid isn't being stored in the drm_device_t yet, but I plan to hook that up. I hadn't planned on there being an ioctl for PCI ID and family. Having a PCI ID ioctl makes some sense to me, as it would be useful for non-X applications of the DRI. However, I don't think exporting the device private info to userland is a good idea. It's just another layer of things to go wrong with versioning, like the issue being discussed right now with mga. Just stick a switch in the userland based off the pci id to decide the family. Given the small number of pci ids for this hardware, it's an easy solution. -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] --- This SF.net email is sponsored by OSDN developer relations Here's your chance to show off your extensive product knowledge We want to know what you know. Tell us and you have a chance to win $100 http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: More expat problems...
glcontextmodes.o gets linked to libGL, not the driver. Apperently you have an outdated libGL installed. Though this kind of binary incompatibility shouldn't happen in the first place. Ian, there is a symbolic link to lib/GL/glx/glcontextmodes.c in lib/GL/dri. I can only guess that the intention is to link glcontextmodes.o to the drivers. However, the only object from lib/GL/dri that the drivers are linked with is dri_util.o. Felix On Mon, 20 Oct 2003 16:37:23 -0700 (PDT) Linus Torvalds [EMAIL PROTECTED] wrote: Am I the only one who sees an undefined _gl_context_modes_destroy() symbol with the current DRI tree on i830? LIBGL_DEBUG gives this: libGL: XF86DRIGetClientDriverName: 1.3.0 i830 (screen 0) libGL: OpenDriver: trying /usr/X11R6/lib/modules/dri/tls/i830_dri.so libGL: OpenDriver: trying /usr/X11R6/lib/modules/dri/i830_dri.so libGL error: dlopen /usr/X11R6/lib/modules/dri/i830_dri.so failed (/usr/X11R6/lib/modules/dri/i830_dri.so: undefined symbol: _gl_context_modes_destroy) libGL error: unable to find driver: i830_dri.so and I do find the definition for this in lib/GL/dri/glcontextmodes.c, but for some reason it apparently hasn't been linked in. I've upgraded this machine to the current Fedora test3 at the same time I did a CVS update, so maybe it's a tools issue? Linus __\|/_____ ___ - Felix ___\_e -_/___/ __\___/ __\_ You can do anything, Kühling (_\Ä// /_/ /) just not everything [EMAIL PROTECTED] \___/ \___/ Uat the same time. --- This SF.net email is sponsored by OSDN developer relations Here's your chance to show off your extensive product knowledge We want to know what you know. Tell us and you have a chance to win $100 http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] Adding hardware detection to DRI drivers
Linus Torvalds writes: On Wed, 15 Oct 2003, Michel Dänzer wrote: On Wed, 2003-10-15 at 21:01, Jon Smirl wrote: This new scheme allows the entire PCI probing stage of xfree to be eliminated. I'll believe it when the relevant XFree86 developers agree with you. :) If they don't, they are clueless. There's no way in _hell_ that XFree86 can do as good a job as the kernel, on as wide a variety of hardware. Basically, if the kernel booted far enough that XFree86 is an issue, then the kernel will know how to probe PCI devices. The same is _not_ true of XFree86. I fully agree with you and I wish this had been true at the time I implemented most of the PCI probing code in XFree86. At that time Linux did not provide all information XFree86 required and also relied on the PCI configuration the BIOS performed at POST time. This configuration proved to be wrong in a lot of cases - at least for non active VGA devices. We had to jump thru hoops bending over backwards to 'guess' some information that we could not savely probe. I'm not sure if PCI probing can be eliminated completely from XFree86 as it was suggested in the original posting as it also needs to run with hardware for which no DRI support is available. Furthermore for RAC (Resource Access Control) it needs to know the bus structure (ie which PCI buses live behind a PCI-PCI bridge on which primary bus). All this information however could be retrieved from the kernel. In fact this is done on all platforms except the 'PC-like' ia32 and AMD64 where direct IO access to the configuration space registers is used for performance reasons. On 'sane' OSes which take care of PCI probing and correcting of PCI resources themselves a lot of the PCI validation code could be bypassed. Unfortunately when I suggested this I was told that this code should stay in for all platforms to get much wider testing. I chose to refrain from starting a flamewar Yes, XF86 may need to have some legacy module for backwards compatibility. But thinking that X should try to probe on its own is just silly. There are things like cardbus or compact flash video cards - you need them for external video on things like an iPAQ. I don't think you _really_ want X to know about every single PCI bridge type out there, present and future, and for every architecture out there. For RAC I just would like to know the bus tree (or better to say the PCI-PCI bridges) and I would like to know if devices behind different host bridges or in different domains are in the same address space to know if VGA resources (which a lot of devices still need) may conflict with each other. The information about PCI host bridges was added for some special purposes (like to know if we are allowed to probe for sparsely located 8514 registers). - A question that is rather academical in nature on the platforms where it arises. Egbert. --- This SF.net email is sponsored by OSDN developer relations Here's your chance to show off your extensive product knowledge We want to know what you know. Tell us and you have a chance to win $100 http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon DRM memory layout transition
Michel Dnzer wrote:
On Wed, 2003-10-08 at 04:34, Vladimir Dergachev wrote:
On Wed, 8 Oct 2003, Michel [ISO-8859-1] Dnzer wrote:
Does the aperture ever (have to) move during the X server life though?
I would not care. However, I know that at least Window 98 drivers have
default position (0) unless capture is enabled. Also, I suspect that when
one calls Video BIOS with framebuffer position anywhere other than 0 the
BIOS then toggles the hard reset line.
Why? (CC'ing Hui Yu, who should be able to comment on this)
No idea why it does it.
Any news on this? I haven't taken this into account in
http://penguinppc.org/~daenzer/DRI/radeon-memory-transition.diff
Would you consider creating a DRM_RADEON_SETPARAM ioctl instead of
DRM_RADEON_FB_LOCATION, with an ioctl struct like:
#define RADEON_SETPARAM_FB_LOCATION 1
typedef struct drm_radeon_setparam {
int param;
int value;
} drm_radeon_setparam_t;
There are other int-valued parameters that I can imagine being set in this way.
Keith
---
This SF.net email is sponsored by OSDN developer relations
Here's your chance to show off your extensive product knowledge
We want to know what you know. Tell us and you have a chance to win $100
http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: More expat problems...
Felix Kühling wrote: glcontextmodes.o gets linked to libGL, not the driver. Apperently you have an outdated libGL installed. Though this kind of binary incompatibility shouldn't happen in the first place. Ian, there is a symbolic link to lib/GL/glx/glcontextmodes.c in lib/GL/dri. I can only guess that the intention is to link glcontextmodes.o to the drivers. However, the only object from lib/GL/dri that the drivers are linked with is dri_util.o. Yes, the original plan was that old libGL.so's should always work at some level with the new driver. Is this incompatibility a deliberate one, or an error? Would it be possible to use dlsym() to extract these newer symbols rather than relying on them being there? Or at least be able to print a meaningful error message? Keith --- This SF.net email is sponsored by OSDN developer relations Here's your chance to show off your extensive product knowledge We want to know what you know. Tell us and you have a chance to win $100 http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] can't get dricvs to use radeon drm
please find attached the XFree86 log and config, also note that if I use the old cvs from SF it works fine with the exact same config also cut from syslog Oct 21 23:56:47 (null) kernel: [drm] Module unloaded Oct 21 23:56:51 (null) kernel: radeon: no version magic, tainting kernel. Oct 21 23:57:13 (null) gconfd (ceison-4002): starting (version 2.2.1), pid 4002 user 'ceison' Oct 21 23:57:13 (null) gconfd (ceison-4002): Resolved address xml:readonly:/etc/gconf/gconf.xml.mandatory to a read-only config source at position 0 Oct 21 23:57:13 (null) gconfd (ceison-4002): Resolved address xml:readwrite:/home/ceison/.gconf to a writable config source at position 1 Oct 21 23:57:13 (null) gconfd (ceison-4002): Resolved address xml:readonly:/etc/gconf/gconf.xml.defaults to a read-only config source at position 2 /end cut # XF86Config-4 (XFree86 X server configuration file) generated by dexconf, the # Debian X Configuration tool, using values from the debconf database. # # Edit this file with caution, and see the XF86Config-4 manual page. # (Type man XF86Config-4 at the shell prompt.) # # This file is automatically updated on xserver-xfree86 package upgrades *only* # if it has not been modified since the last upgrade of the xserver-xfree86 # package. # # If you have edited this file but would like it to be automatically updated # again, run the following commands as root: # # cp /etc/X11/XF86Config-4 /etc/X11/XF86Config-4.custom # md5sum /etc/X11/XF86Config-4 /var/lib/xfree86/XF86Config-4.md5sum # dpkg-reconfigure xserver-xfree86 Section Files FontPathunix/:7100# local font server # if the local font server has problems, we can fall back on these FontPath/usr/lib/X11/fonts/Type1 FontPath/usr/lib/X11/fonts/CID FontPath/usr/lib/X11/fonts/Speedo FontPath/usr/lib/X11/fonts/misc FontPath/usr/lib/X11/fonts/cyrillic FontPath/usr/lib/X11/fonts/100dpi FontPath/usr/lib/X11/fonts/75dpi EndSection Section Module LoadGLcore Loadbitmap Loaddbe Loadddc Loaddri Loadextmod Loadfreetype Loadglx Loadint10 Loadrecord Loadspeedo Loadtype1 Loadvbe EndSection Section InputDevice Identifier Generic Keyboard Driver keyboard Option CoreKeyboard Option XkbRules xfree86 Option XkbModel pc104 Option XkbLayout us EndSection Section InputDevice Identifier Configured Mouse Driver mouse Option CorePointer Option Device/dev/psaux Option Protocol ImPS/2 Option Emulate3Buttons false Option Buttons 5 Option ZAxisMapping 4 5 EndSection Section InputDevice Identifier Generic Mouse Driver mouse Option SendCoreEventstrue Option Device/dev/input/mice Option Protocol ImPS/2 Option ZAxisMapping 4 5 EndSection Section Device Identifier ati9000pci Driver ati Option ForcePCIMode EndSection Section Monitor Identifier Generic Monitor HorizSync 30-58 VertRefresh 50-100 Option DPMS EndSection Section Screen Identifier Default Screen Device ati9000pci Monitor Generic Monitor DefaultDepth24 SubSection Display Depth 1 Modes 1024x768 800x600 640x480 EndSubSection SubSection Display Depth 4 Modes 1024x768 800x600 640x480 EndSubSection SubSection Display Depth 8 Modes 1024x768 800x600 640x480 EndSubSection SubSection Display Depth 15 Modes 1024x768 800x600 640x480 EndSubSection SubSection Display Depth 16 Modes 1024x768 800x600 640x480 EndSubSection SubSection Display Depth 24 Modes 1024x768 800x600 640x480 EndSubSection EndSection Section ServerLayout Identifier Default Layout Screen Default Screen InputDevice Generic Keyboard InputDevice Configured Mouse EndSection Section DRI Mode0666 EndSection This is a pre-release version of XFree86, and is not supported in any way. Bugs may be
Re: [Dri-devel] Radeon DRM memory layout transition
Michel Dnzer wrote: On Wed, 2003-10-08 at 04:34, Vladimir Dergachev wrote: On Wed, 8 Oct 2003, Michel [ISO-8859-1] Dnzer wrote: Does the aperture ever (have to) move during the X server life though? I would not care. However, I know that at least Window 98 drivers have default position (0) unless capture is enabled. Also, I suspect that when one calls Video BIOS with framebuffer position anywhere other than 0 the BIOS then toggles the hard reset line. Why? (CC'ing Hui Yu, who should be able to comment on this) No idea why it does it. Any news on this? I haven't taken this into account in http://penguinppc.org/~daenzer/DRI/radeon-memory-transition.diff In r200_screen.c, you check for drmMinor = 10 before issuing the FB_LOCATION ioctl, but it's not clear what happens if drmMinor 10 -- will the driver function correctly? If not, what should happen? Also, it seems this patch does two things, one is the fblocation stuff, but there's also some chipset_id changes relating to the R200_CHIPSET_RS300. I'd be happier to see these in separate patches. In radeon_state.c, the tests in radeon_emit_packets() are just ugly. The normal usage for this code on a properly installed system is that (filp_priv-fboffset == 0), right? So all those tests are going to result in a noop? Could the tests be pushed into their own functions and shortcircuited witha single test on (fboffset == 0) ? Additionally, in those tests, it looks like you are reading back and fixing up the data on the ring -- ie from uncached memory! Especially when (fboffset == 0) this is a very wasteful noop... Finally, and just being picky -- it'd be nice to keep the number of coding styles fairly minimal. It just looks a little odd to start seeing the spaces in code like 'tmp[ 0 ]', while the rest of the module is 'tmp[0]' Keith --- This SF.net email is sponsored by OSDN developer relations Here's your chance to show off your extensive product knowledge We want to know what you know. Tell us and you have a chance to win $100 http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon DRM memory layout transition
On Tue, 2003-10-21 at 05:14, Eric Anholt wrote: One small problem in radeon_fb_location ioctl: For OS-independence, so far filp has been an opaque void pointer. I'm wondering if maybe we want to pass the drm_file_t * as part of DRM_IOCTL_ARGS, or just resurrect DRM_PRIV to get the drm_file_t * based on filp. I have no opinion on which one is better, but either is definitely needed for this to work. :) -- Earthling Michel Dnzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer --- This SF.net email is sponsored by OSDN developer relations Here's your chance to show off your extensive product knowledge We want to know what you know. Tell us and you have a chance to win $100 http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [patch] Dithering options for radeon and r200
On Mon, 2003-10-20 at 23:46, Felix Khling wrote: I attached a patch that adds color dithering and rounding options to the radeon and r200 drivers. I'd like to hear some comments about the semantics of the options I chose before I commit anything [...] Is there a reason why dithering and rounding/truncation are separate options? As a side note, the X error diffusion with reset at start of lines looks broken on my Radeon 7500. It produces very noticable vertical patterns. Does it work better on other cards? Is it supposed to work well? :) -- Earthling Michel Dnzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer --- This SF.net email is sponsored by OSDN developer relations Here's your chance to show off your extensive product knowledge We want to know what you know. Tell us and you have a chance to win $100 http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] can't get dricvs to use radeon drm
On Tue, 2003-10-21 at 16:03, Chris Ison wrote: Oct 21 23:56:51 (null) kernel: radeon: no version magic, tainting kernel. This happens here when I insmod radeon.o instead of radeon.ko with a 2.6 kernel. It still works though, what happens if you try to load the module manually? If you're using radeonfb in console, it could be the new DRM PCI probing code which prevents it from loading if the devices it supports have already been claimed. -- Earthling Michel Dnzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer --- This SF.net email is sponsored by OSDN developer relations Here's your chance to show off your extensive product knowledge We want to know what you know. Tell us and you have a chance to win $100 http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] can't get dricvs to use radeon drm
On Tue, 2003-10-21 at 21:29, Michel Dänzer wrote: On Tue, 2003-10-21 at 16:03, Chris Ison wrote: Oct 21 23:56:51 (null) kernel: radeon: no version magic, tainting kernel. This happens here when I insmod radeon.o instead of radeon.ko with a 2.6 kernel. It still works though, what happens if you try to load the module manually? If you're using radeonfb in console, it could be the new DRM PCI probing code which prevents it from loading if the devices it supports have already been claimed. This was manually loaded, the XFree86 log (from previous email) showed X/DRI trying to load the module (from freedesktop xc cvs) but failing. As stated in previous email, same config, using current SF cvs of xc works without problem. For some reason its failing to open /dev/drm/card0, the SF version opens it without problems. --- This SF.net email is sponsored by OSDN developer relations Here's your chance to show off your extensive product knowledge We want to know what you know. Tell us and you have a chance to win $100 http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [patch] Dithering options for radeon and r200
On Tue, 21 Oct 2003 13:23:52 +0200 Michel Dänzer [EMAIL PROTECTED] wrote: On Mon, 2003-10-20 at 23:46, Felix Kühling wrote: I attached a patch that adds color dithering and rounding options to the radeon and r200 drivers. I'd like to hear some comments about the semantics of the options I chose before I commit anything [...] Is there a reason why dithering and rounding/truncation are separate options? Dithering is used if the app enables dithering or dithering if is enabled by default. Rounding/truncation is used if dithering is disabled. So both need to be configured separately. An alternative I had considered was to make Rounding one more choice in the dithering option. That is, the dithering switch would actually switch between truncation and rounding instead of between truncation and dithering if rounding is selected as dithering mode. As a side note, the X error diffusion with reset at start of lines looks broken on my Radeon 7500. It produces very noticable vertical patterns. Does it work better on other cards? Is it supposed to work well? :) I just know what you wrote about the spec. It looks like there is something else going on though. ?-| -- Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer __\|/_____ ___ - Felix ___\_e -_/___/ __\___/ __\_ You can do anything, Kühling (_\Ä// /_/ /) just not everything [EMAIL PROTECTED] \___/ \___/ Uat the same time. --- This SF.net email is sponsored by OSDN developer relations Here's your chance to show off your extensive product knowledge We want to know what you know. Tell us and you have a chance to win $100 http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon DRM memory layout transition
On Tue, 2003-10-21 at 03:53, Vladimir Dergachev wrote: On Tue, 21 Oct 2003, Michel [ISO-8859-1] Dnzer wrote: On Tue, 2003-10-21 at 03:35, Vladimir Dergachev wrote: 2) I would have expected SetFBLocation function to make sure that the card is idle. Maybe this is done someplace else ? Not explicitly yet, but that's easy enough to add. Is there anything else to be careful about there? Well, I'll have to take a closer look when I get a solid chunk of spare time. Any idea how soon that will be? I was originally hoping to sneak this into XFree86 4.4, but that's getting less likely by the day. What code are you working against XFree86 CVS or DRI CVS ? DRI CVS for now, but there shouldn't be much difference between the two yet. -- Earthling Michel Dnzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer --- This SF.net email is sponsored by OSDN developer relations Here's your chance to show off your extensive product knowledge We want to know what you know. Tell us and you have a chance to win $100 http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon DRM memory layout transition
On Tue, 2003-10-21 at 11:06, Keith Whitwell wrote:
In r200_screen.c, you check for drmMinor = 10 before issuing the FB_LOCATION
ioctl, but it's not clear what happens if drmMinor 10 -- will the driver
function correctly? [...]
Yes. The driver determines the memory layout from the chip registers,
the ioctl just improves the DRM's ability to check and fix up state.
Also, it seems this patch does two things, one is the fblocation stuff, but
there's also some chipset_id changes relating to the R200_CHIPSET_RS300. I'd
be happier to see these in separate patches.
I can commit these parts separately once everybody is happy, but I'll
keep them together for now due to
http://bugs.xfree86.org/show_bug.cgi?id=314 .
In radeon_state.c, the tests in radeon_emit_packets() are just ugly. The
normal usage for this code on a properly installed system is that
(filp_priv-fboffset == 0), right? So all those tests are going to result in
a noop? Could the tests be pushed into their own functions and shortcircuited
witha single test on (fboffset == 0) ?
So I thought first, but then it occurred to me that there's no guarantee
that clients use sensible memory offsets at all, so I think it's a good
idea always to check them (even for the older ioctls, on second though)
to prevent bad things from happening.
Additionally, in those tests, it looks like you are reading back and fixing up
the data on the ring -- ie from uncached memory! Especially when (fboffset ==
0) this is a very wasteful noop...
Well, I haven't noticed any significant performance impact, but I can
change that I guess.
Finally, and just being picky -- it'd be nice to keep the number of coding
styles fairly minimal. It just looks a little odd to start seeing the spaces
in code like 'tmp[ 0 ]', while the rest of the module is 'tmp[0]'
Point taken. It's just that I've grown to like the spaces a lot (partly
because of you ;), but they're certainly less important for square
brackets.
Would you consider creating a DRM_RADEON_SETPARAM ioctl instead of
DRM_RADEON_FB_LOCATION, with an ioctl struct like:
#define RADEON_SETPARAM_FB_LOCATION 1
typedef struct drm_radeon_setparam {
int param;
int value;
} drm_radeon_setparam_t;
There are other int-valued parameters that I can imagine being set in this way.
Good idea.
Thanks for your suggestions, I'll integrate them and post an updated
patch ASAP.
--
Earthling Michel Dnzer \ Debian (powerpc), XFree86 and DRI developer
Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer
---
This SF.net email is sponsored by OSDN developer relations
Here's your chance to show off your extensive product knowledge
We want to know what you know. Tell us and you have a chance to win $100
http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] can't get dricvs to use radeon drm
forgot to mention I don't use radeonfb and ldmod shows the module not in use (null):/home/ceison# lsmod | grep radeon radeon117648 0 (null):/home/ceison# --- This SF.net email is sponsored by OSDN developer relations Here's your chance to show off your extensive product knowledge We want to know what you know. Tell us and you have a chance to win $100 http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: More expat problems...
Felix Kühling wrote: glcontextmodes.o gets linked to libGL, not the driver. Apperently you have an outdated libGL installed. Though this kind of binary incompatibility shouldn't happen in the first place. Ian, there is a symbolic link to lib/GL/glx/glcontextmodes.c in lib/GL/dri. I can only guess that the intention is to link glcontextmodes.o to the drivers. However, the only object from lib/GL/dri that the drivers are linked with is dri_util.o. Not true. It gets linked both places. I updated the Imakefiles to create a symbolic link from lib/GL/glx/glcontextmodes.c to lib/GL/dri/glcontextmodes.c. It also gets linked to programs/Xserver/GL/glx/glcontextmodes.c. The XFree86 build process is just wacky that way. :) In any case a 'make World' (or at least 'make Makefiles') is probably in order. I am able to build a clean CVS checkout. --- This SF.net email is sponsored by OSDN developer relations Here's your chance to show off your extensive product knowledge We want to know what you know. Tell us and you have a chance to win $100 http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon DRM memory layout transition
On Tue, 21 Oct 2003, Michel [ISO-8859-1] Dänzer wrote: On Tue, 2003-10-21 at 03:53, Vladimir Dergachev wrote: On Tue, 21 Oct 2003, Michel [ISO-8859-1] Dnzer wrote: On Tue, 2003-10-21 at 03:35, Vladimir Dergachev wrote: 2) I would have expected SetFBLocation function to make sure that the card is idle. Maybe this is done someplace else ? Not explicitly yet, but that's easy enough to add. Is there anything else to be careful about there? Well, I'll have to take a closer look when I get a solid chunk of spare time. Any idea how soon that will be? I was originally hoping to sneak this into XFree86 4.4, but that's getting less likely by the day. No idea unfortunately. I'll be very busy the next three weeks and to make tests I would need to port GATOS code to DRI CVS. There should be a lot of changes at least in the mach64 code, but likely elsewhere as well. It is very tempting though ;) best Vladimir Dergachev What code are you working against XFree86 CVS or DRI CVS ? DRI CVS for now, but there shouldn't be much difference between the two yet. -- Earthling Michel Dnzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer --- This SF.net email is sponsored by OSDN developer relations Here's your chance to show off your extensive product knowledge We want to know what you know. Tell us and you have a chance to win $100 http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon DRM memory layout transition
Keith Whitwell wrote:
Would you consider creating a DRM_RADEON_SETPARAM ioctl instead of
DRM_RADEON_FB_LOCATION, with an ioctl struct like:
#define RADEON_SETPARAM_FB_LOCATION 1
typedef struct drm_radeon_setparam {
int param;
int value;
} drm_radeon_setparam_t;
If this is done, I would *strongly* suggest that the type of value by
int64_t or something similar. We have enough places where mixed 32/64
systems will break, we don't need to add more. On PPC64 where mixed
mode is supported, sizeof(int) != sizeof(void*). I assume the same is
true on IA-64, x86-64, and SPARC64.
Other than that, I am in favor of adding this as a more generic interface.
---
This SF.net email is sponsored by OSDN developer relations
Here's your chance to show off your extensive product knowledge
We want to know what you know. Tell us and you have a chance to win $100
http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Adding hardware detection to DRI drivers
On Tue, 2003-10-21 at 15:33, Linus Torvalds wrote: On Tue, 21 Oct 2003, Eric Anholt wrote: What is the proper way to get the equivalent of pci_name(pdev) on pre-2.5? Also, what is the cutoff where pci_name is available? Are the values from pci_name decimal or hex? The cut-off is 2.5.74 or so. The numbers are hex, and it's really implemented by just caching the result of sprintf(string, %04x:%02x:%02x.%d, pci_domain_nr(dev-bus), dev-bus-number, PCI_SLOT(dev-devfn), PCI_FUNC(dev-devfn)); (that last %d is irrelevant - the number is alway sin the range 0..7, so it's same in decimal, octal and hex ;). pci_name() is more convenient in printouts etc. If backwards compatibility of compatibility with *BSD makes pci_name() inconvenient, feel free to do it by hand like this, but the important parts I had were: - _please_ use the domain number. There are real machines with multiple independent PCI buses. We've already seen some real-life problems with drivers that look for companion chips without knowing about the domain thing, and as a result they find the wrong chip. The domain problem is rare today, but it will likely be less rare tomorrow. - please start thinking of the day when DRI won't be all about PCI, and the naming might be more complicated than the normal domain/bus/slot/func thing. Thus the suggestion to tag the address with the address type information. So whether you use pci_name() or anything else is much less important than the two points above. Excellent, this was just the info I wanted. I think this is all being covered in the changes I'm making now. The issue here was compatibility with linux 2.4.x, and possibly interpreting the busid in the X Server (not 100% sure if I'll need it in the end yet). For pre-2.5.74 I'm using a domain number of 0 on non-alpha and hose-bus-number on alpha, because of the lack of pci_domain_nr(), at least on the 2.4.19 I'm using I still need to figure out how XFree86 deals with domains, and if I can get the busid from XFree86 to match this format. The busid begins with pci:, and currently the DRM has that hardcoded, but it can be changed when we get non-pci drivers. Similarly for libdrm, so far. -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] --- This SF.net email is sponsored by OSDN developer relations Here's your chance to show off your extensive product knowledge We want to know what you know. Tell us and you have a chance to win $100 http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon DRM memory layout transition
On Tue, 2003-10-21 at 17:13, Vladimir Dergachev wrote: On Tue, 21 Oct 2003, Michel [ISO-8859-1] Dnzer wrote: On Tue, 2003-10-21 at 03:53, Vladimir Dergachev wrote: On Tue, 21 Oct 2003, Michel [ISO-8859-1] Dnzer wrote: On Tue, 2003-10-21 at 03:35, Vladimir Dergachev wrote: 2) I would have expected SetFBLocation function to make sure that the card is idle. Maybe this is done someplace else ? Not explicitly yet, but that's easy enough to add. Is there anything else to be careful about there? Well, I'll have to take a closer look when I get a solid chunk of spare time. Any idea how soon that will be? I was originally hoping to sneak this into XFree86 4.4, but that's getting less likely by the day. No idea unfortunately. I'll be very busy the next three weeks and to make tests I would need to port GATOS code to DRI CVS. There should be a lot of changes at least in the mach64 code, but likely elsewhere as well. Err, what does Mach64 have to do with this? :) Anyway, I think the most important point is that the DRM should be able to deal with whatever you throw at it this way; the details can still be changed later. Agreed? -- Earthling Michel Dnzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer --- This SF.net email is sponsored by OSDN developer relations Here's your chance to show off your extensive product knowledge We want to know what you know. Tell us and you have a chance to win $100 http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] can't get dricvs to use radeon drm
Have you done all the proper idiot checks? I hate to use the word that way, but that's how I'd phrase it if I were speaking to myself... Have you checked to make sure /dev/dri/card0 exists, has the proper major and minor numbers, and is readable and writeable by root? ok, /dev/dri/card0 doesn't exists, so why does it work for the SF dri and not the freedesktop one ... /dev/dri does exist, I'm thinking the SF drm creates /dev/dri/card0 but the freedesktop one doesn't, but I could be wrong. I will investigate this further by reverting back to the SF cvs. --- This SF.net email is sponsored by OSDN developer relations Here's your chance to show off your extensive product knowledge We want to know what you know. Tell us and you have a chance to win $100 http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon DRM memory layout transition
time. Any idea how soon that will be? I was originally hoping to sneak this into XFree86 4.4, but that's getting less likely by the day. No idea unfortunately. I'll be very busy the next three weeks and to make tests I would need to port GATOS code to DRI CVS. There should be a lot of changes at least in the mach64 code, but likely elsewhere as well. Err, what does Mach64 have to do with this? :) Either I port the whole thing, or it is a one big hack.. ;) Anyway, I think the most important point is that the DRM should be able to deal with whatever you throw at it this way; the details can still be changed later. Agreed? DRM and DRI drivers. :) best Vladimir Dergachev -- Earthling Michel Dnzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer --- This SF.net email is sponsored by OSDN developer relations Here's your chance to show off your extensive product knowledge We want to know what you know. Tell us and you have a chance to win $100 http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] can't get dricvs to use radeon drm
On Wed, 2003-10-22 at 00:55, Chris Ison wrote: Have you done all the proper idiot checks? I hate to use the word that way, but that's how I'd phrase it if I were speaking to myself... Have you checked to make sure /dev/dri/card0 exists, has the proper major and minor numbers, and is readable and writeable by root? ok, /dev/dri/card0 doesn't exists, so why does it work for the SF dri and not the freedesktop one ... /dev/dri does exist, I'm thinking the SF drm creates /dev/dri/card0 but the freedesktop one doesn't, but I could be wrong. I will investigate this further by reverting back to the SF cvs. Note that the X Server will first try to create /dev/dri/cardX if it's missing, chmod/chown /dev/dri/cardX according to your settings in XF86Config, then open /dev/dri/cardX. If that fails, it checks that the device major/minor matches its expectations and recreates it if necessary, then tries opening again. That said, I'm not sure what's going on here, if you actually have the module loaded and the kernel printed the info line (the radeon equivalent of [drm] Initialized mga 3.1.0 20021029 on minor 0). If the module's loaded and it's not printing the line, then I need the output of scanpci, I think. -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] --- This SF.net email is sponsored by OSDN developer relations Here's your chance to show off your extensive product knowledge We want to know what you know. Tell us and you have a chance to win $100 http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon DRM memory layout transition
On Wed, 2003-10-22 at 01:59, Vladimir Dergachev wrote: Anyway, I think the most important point is that the DRM should be able to deal with whatever you throw at it this way; the details can still be changed later. Agreed? DRM and DRI drivers. :) What do you mean? Old 3D drivers work with this unchanged. -- Earthling Michel Dnzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer --- This SF.net email is sponsored by OSDN developer relations Here's your chance to show off your extensive product knowledge We want to know what you know. Tell us and you have a chance to win $100 http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] [Bug 314] 3D support for Radeon IGP chips
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter your comments there. http://bugs.xfree86.org/show_bug.cgi?id=314 --- Additional Comments From [EMAIL PROTECTED] 2003-21-10 18:43 --- Thanks to everyone in here i'm looking at fluxbox running glgears at 400fps whilst emerging firebird on my nice gentoo development-sources box Linux laptop 2.6.0-test6 #1 Sat Oct 18 20:09:32 BST 2003 i686 mobile AMD Athlon(tm) XP 2000+ AuthenticAMD GNU/Linux Thanks a lot, this is brilliant. -- Configure bugmail: http://bugs.xfree86.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This SF.net email is sponsored by OSDN developer relations Here's your chance to show off your extensive product knowledge We want to know what you know. Tell us and you have a chance to win $100 http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] DRI CVS Running slow
Is anyone aware, or know how to resolve the slowness of the current DRI CVS, I'm only getting 30fps with glxgears compared to the 250+fps with the SF dri cvs. Note, Direct Rendering is enabled name of display: :0.0 display: :0 screen: 0 direct rendering: Yes server glx vendor string: SGI server glx version string: 1.2 --- This SF.net email is sponsored by OSDN developer relations Here's your chance to show off your extensive product knowledge We want to know what you know. Tell us and you have a chance to win $100 http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] America's Army 1.9.0 rendering bugs on radeon hardware
On Wed, 2003-10-22 at 00:58, Louis Garcia wrote: I'm running a radeon-7500 card and been playing wolfenstein and quake3 just fine under Fedora Core 3 (redhat beta). I just got America's Army to try it. Well it runs fine but the 3D rendering is messed up. How can I tell if this is a dri bug or a game bug? Is anyone playing this game? This bug report is exactly what I'm experiencing: https://bugzilla.icculus.org/show_bug.cgi?id=695 According to https://bugzilla.icculus.org/show_bug.cgi?id=695#c8 it works with a DRI CVS snapshot from September though. Have you tried a recent DRI CVS snapshot? -- Earthling Michel Dnzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer --- This SF.net email is sponsored by OSDN developer relations Here's your chance to show off your extensive product knowledge We want to know what you know. Tell us and you have a chance to win $100 http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] can't get dricvs to use radeon drm
On Wed, 2003-10-22 at 00:06, Chris Ison wrote: For some reason its failing to open /dev/drm/card0, the SF version opens it without problems. Even with the same DRM? My best guess is still that this is related to the new DRM PCI probing code which was committed last Friday. Maybe it can't deal correctly with the two PCI instances your chip exposes yet or something. Eric or Jon, any suggestions for how to debug this? ok, /dev/dri/card0 doesn't exists, so why does it work for the SF dri and not the freedesktop one ... /dev/dri does exist, I'm thinking the SF drm creates /dev/dri/card0 but the freedesktop one doesn't, but I could be wrong. Indeed (note the error: 'No such device', not 'No such file or directory'), the X server has always created the device nodes on the fly. I will investigate this further by reverting back to the SF cvs. Why SF? The CVS repository at freedesktop.org contains all the history. -- Earthling Michel Dnzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer --- This SF.net email is sponsored by OSDN developer relations Here's your chance to show off your extensive product knowledge We want to know what you know. Tell us and you have a chance to win $100 http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRI CVS Running slow
Chris Ison wrote: Is anyone aware, or know how to resolve the slowness of the current DRI CVS, I'm only getting 30fps with glxgears compared to the 250+fps with the SF dri cvs. Check logs for reports of breakage... could be engine resetting itself a whole lot or something. Just a random thought from a non-developer. David Bronaugh --- This SF.net email is sponsored by OSDN developer relations Here's your chance to show off your extensive product knowledge We want to know what you know. Tell us and you have a chance to win $100 http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] versioning ioctl and unique changes
http://people.freebsd.org/~anholt/dri/files/drm-unique-2.diff Here's my first shot at the changes for unique handling in the DRI. It includes a new ioctl, DRM_IOCTL_SET_VERSION. This takes in a struct containing numbers for the major/minor version of the device independent DRM interface and major/minor of the device dependent interface version (the version numbers we're familiar with for the DRM modules). If the DI interface version is 1.1, we set the busid based off of the PCI device we probed as. It's in the pci::bb:dd.f format as Linus requested. The *_dri.c in the DDX have been converted to use a new libdri function DRICreatePCIBusID which also creates a busid in that format. libdrm understands both of these formats. If the DI interface version doesn't get set, then the DRM behaves in the same way as before (haven't tested it again to be sure yet). Nothing uses the DD interface version number yet, but there's a simple hook in there for it. The setversion ioctl returns the actual versions of the DI and DD interfaces in the structure that was passed to it. Things I'm thinking about: - What should the DRM do if the minor number for either DI or DD interface is greater than the DRM knows about? - Need to limit setting of the general interface version to root (X Server) probably. Not an issue with the current version, though. - Can we deprecate SET_UNIQUE? My idea is that the ioctl would still function, but call set_busid like the new interface version does and then return an error if the unique being set is not equivalent to the device's. This would break some DRI setups with multiple cards of a single type in a system with an old X Server. - Do we want to put some reserved fields in the SET_VERSION ioctl in case we want to extend it in some manner in the future? - Do we want to create an ioctl to get the PCI ID from the DRM? If we do, I would also like to put the IRQ number in there, too. I want to deprecate the irq-from-busid feature (particularly given the concerns about domains), at least lobotomizing it to only check that the busid info passed in matches the device's and then return the irq for the device. - Should the libdri minor version be bumped for the new DRICreatePCIBusID function? Is using xf86LoaderCheckSymbol the way to see if it's available, and does it need to be in the symbol lists for the drivers? - I would like to move xf86drm.c to shared/drm/ (it's a shared file anyway). Is there any value in the /proc/ support in it any more? - drm.h should probably get re-merged and put into shared/ -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] --- This SF.net email is sponsored by OSDN developer relations Here's your chance to show off your extensive product knowledge We want to know what you know. Tell us and you have a chance to win $100 http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] [Bug 314] 3D support for Radeon IGP chips
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter your comments there. http://bugs.xfree86.org/show_bug.cgi?id=314 --- Additional Comments From [EMAIL PROTECTED] 2003-21-10 17:07 --- There is news for my problem : I use kernel 2.6.0-test7 with patch #706 and XFree86 4.3.99.14 with patch #723 on a compaq presario 2141ea (IGP 320M) I've done a ssh connexion during a 3D test : When the system freeze, I have glxgear that takes all the resources CPU. When I kill it with KILL signal, XFree86 takes all the resources CPU, and I can't kill it (root with KILL signal). TERM signal does nothing on both processi. I can reboot. If anyone have an idea, I'd like to use 3D... If you have more questions, or you have any debug idea, I can do it without problems. Thanks for you're job. -- Configure bugmail: http://bugs.xfree86.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This SF.net email is sponsored by OSDN developer relations Here's your chance to show off your extensive product knowledge We want to know what you know. Tell us and you have a chance to win $100 http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon DRM memory layout transition
On Tue, 2003-10-21 at 20:55, Ian Romanick wrote:
Keith Whitwell wrote:
Would you consider creating a DRM_RADEON_SETPARAM ioctl instead of
DRM_RADEON_FB_LOCATION, with an ioctl struct like:
#define RADEON_SETPARAM_FB_LOCATION 1
typedef struct drm_radeon_setparam {
int param;
int value;
} drm_radeon_setparam_t;
If this is done, I would *strongly* suggest that the type of value by
int64_t or something similar.
I tried u32 for fb_location initially, the problem is that radeon_drm.h
is also included in
programs/Xserver/hw/xfree86/os-support/linux/drm/xf86drmCompat.c, where
this doesn't work.
--
Earthling Michel Dnzer \ Debian (powerpc), XFree86 and DRI developer
Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer
---
This SF.net email is sponsored by OSDN developer relations
Here's your chance to show off your extensive product knowledge
We want to know what you know. Tell us and you have a chance to win $100
http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon DRM memory layout transition
On Tue, 2003-10-21 at 11:55, Ian Romanick wrote:
Keith Whitwell wrote:
Would you consider creating a DRM_RADEON_SETPARAM ioctl instead of
DRM_RADEON_FB_LOCATION, with an ioctl struct like:
#define RADEON_SETPARAM_FB_LOCATION 1
typedef struct drm_radeon_setparam {
int param;
int value;
} drm_radeon_setparam_t;
If this is done, I would *strongly* suggest that the type of value by
int64_t or something similar. We have enough places where mixed 32/64
systems will break, we don't need to add more. On PPC64 where mixed
mode is supported, sizeof(int) != sizeof(void*). I assume the same is
true on IA-64, x86-64, and SPARC64.
Other than that, I am in favor of adding this as a more generic interface.
Would we ever be setting pointers through a setparam interface? I think
making it an int makes it relatively clear that it's a 32-bit value,
though it might be valuable to use [u]intXX_t for the drm (and dri
screen private?) sruct definitions everywhere to make things clear.
Also, yes, alpha, amd64, ia64, and sparc64 all have 32-bit ints and
64-bit longs and pointers.
Hmm, just noticed that the SiS dri/ddx/drm interactions are rather
64-bit unclean. I thought I had fixed that.
--
Eric Anholt[EMAIL PROTECTED]
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED]
---
This SF.net email is sponsored by OSDN developer relations
Here's your chance to show off your extensive product knowledge
We want to know what you know. Tell us and you have a chance to win $100
http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
