I think this is used to adjust for other drivers that may set the
beginning of the framebuffer to a different location than DRI. (I wish
we would just set this in the same place in GPU space and CPU space
instead of having them be different).

I'm trying to figure out how to get rid of the need for root priv when
running r200_dri.so. The only register usage are three INREG's in
r200_screen.c. 

This sequence is always going to require root priv so I need to figure
out another solution.

screen->fbLocation = ( INREG( RADEON_MC_FB_LOCATION ) & 0xffff ) << 16;
sp.param = RADEON_SETPARAM_FB_LOCATION;
sp.value = screen->fbLocation;
drmCommandWrite( sPriv->fd, DRM_RADEON_SETPARAM, &sp, sizeof( sp ) );

I'm also confused about use of screen->fbLocation. I thought the R200
driver assumed the FB was at zero and the AGP memory was directly after
it. With that assumption I can understand RADEON_SETPARAM_FB_LOCATION
and the fixup routines in the driver. But why are values adjusted for
screen->fbLocation in eight other locations in the DRI code? Shouldn't
the DRI driver always work with the zero starting address and these
eight values be fixed up in the driver? Why isn't the whole
filp_priv->radeon_fb_delta issue handled in the driver without the DRI
code even know that it is happening?

=====
Jon Smirl
[EMAIL PROTECTED]


                
__________________________________
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.
http://promotions.yahoo.com/new_mail 


-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com
--
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Reply via email to