nasty little bug in radeon driver
Hi, after having some problems with an R300 based ATI card (dotclocks seemed to be too slowed by a factor of about 1.17, text mode restoral didn't work), I've found the following: Index: radeon_reg.h === RCS file: /cvs/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_reg.h,v retrieving revision 1.25 diff -u -r1.25 radeon_reg.h --- radeon_reg.h2003/02/07 18:08:59 1.25 +++ radeon_reg.h2003/03/07 08:34:09 @@ -879,7 +879,7 @@ # define RADEON_P2PLL_REF_DIV_MASK0x03ff # define RADEON_P2PLL_ATOMIC_UPDATE_R (1 15) /* same as _W */ # define RADEON_P2PLL_ATOMIC_UPDATE_W (1 15) /* same as _R */ -# define R300_PPLL_REF_DIV_ACC_MASK (0x3ff 18) +# define R300_PPLL_REF_DIV_ACC_MASK (0x3ff 18) # define R300_PPLL_REF_DIV_ACC_SHIFT 18 #define RADEON_PALETTE_DATA 0x00b4 #define RADEON_PALETTE_30_DATA 0x00b8 Now it works for me. Cheers, Enrik ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: nasty little bug in radeon driver
On Fri, Mar 07, 2003 at 09:47:42AM +0100, Enrik Berkhan wrote: Hi, after having some problems with an R300 based ATI card (dotclocks seemed to be too slowed by a factor of about 1.17, text mode restoral didn't work), I've found the following: Index: radeon_reg.h === RCS file: /cvs/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_reg.h,v retrieving revision 1.25 diff -u -r1.25 radeon_reg.h --- radeon_reg.h 2003/02/07 18:08:59 1.25 +++ radeon_reg.h 2003/03/07 08:34:09 @@ -879,7 +879,7 @@ # define RADEON_P2PLL_REF_DIV_MASK0x03ff # define RADEON_P2PLL_ATOMIC_UPDATE_R (1 15) /* same as _W */ # define RADEON_P2PLL_ATOMIC_UPDATE_W (1 15) /* same as _R */ -# define R300_PPLL_REF_DIV_ACC_MASK (0x3ff 18) +# define R300_PPLL_REF_DIV_ACC_MASK (0x3ff 18) # define R300_PPLL_REF_DIV_ACC_SHIFT 18 #define RADEON_PALETTE_DATA 0x00b4 #define RADEON_PALETTE_30_DATA 0x00b8 Now it works for me. Thanks, I've committed your fix to the CVS. Alan. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Multiple video consoles
On Fri, Mar 07, 2003 at 12:31:18PM +, Dr Andrew C Aitchison wrote:
On Fri, 7 Mar 2003, Sven Luther wrote:
I don't really agree here, modes are for the outgoing resolution, not
the input viewport. it would be far simpler to keep this simple
acceptation, and add a new keyword for defining the input viewport.
Have you looked at the Stretch option on say the NeoMagic driver ?
I have a 1024x768 laptop display, and by default (ie unless I use
option noStretch) all modes are stretched to fill the screen.
Thus the modes (and modelines) describe the viewport size, not the
output resolution.
Interesting, i suppose the scaling is also done in the driver then, i will
have a look at how it works when i get some free time.
I wonder how the driver knows what the laptop display size is ? do you
specify or does the monitor tell the driver about it with ddc ?
So I don't agree with your description of what the words currently mean.
Using viewport to describe the visible pixels of the
framebuffer and modes to describe the pixels of the monitor would be
logical and consistent, but it does mean a change from the way modes
is considered now.
Well, if you consider that the size given for the modes and the size of
the framebuffer are mostly exactly the same, you can hardly argue that
using modes for the framebuffer size is what most people think of when
they hear of modes.
Also, you have to consider how things work out from the driver
internals.
There is the DisplayModePtr mode, which as its name says is for the
outgoing mode, and has all the monitor timings. On the other hand, the
viewport source position and size is given by pScrn-frame{XY}{01},
which i suppose are calculated from the viewport (usually 0,0) and the
size of the current mode. Other framebuffer info include the
displaywidth (given by the virtual size, i guess) and the pixel depth.
So, we can do it in two ways :
1) As i said, we simply add the size to the viewport keywords, which
would be used to generate pScrn-frame{XY}{01}. No further driver
changes are needed, apart from setting the appropriate scaling factor,
or reject scaled modes if scalling is not allowed.
2) We do it the other way, we use the mode info to mean the viewport
source size. There is no way to set the real outgoing mode, so you can
only hope that the monitor provides you the real data (unless you add
a supported resolutions option to the monitor entry). And even such,
you have to calculate the new outgoing mode, and there is no practical
way for the user to specify the exact timing of the outgoing mode. No,
there is, i suppose you would be able to use a Supported line in the
monitor section and have there the lists of supported modes.
Both solution have advantages and disadvantages, i personnally think
that 1) is better, especially if you want to do more advanced stuff
later on, like zooming on windows (you would just call adjustframe each
time the window is moved) or such, it is also the one that needs least
overall changes.
Friendly,
Sven Luther
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: Multiple video consoles
On Fri, 7 Mar 2003, Sven Luther wrote: On Fri, Mar 07, 2003 at 12:31:18PM +, Dr Andrew C Aitchison wrote: On Fri, 7 Mar 2003, Sven Luther wrote: I don't really agree here, modes are for the outgoing resolution, not the input viewport. it would be far simpler to keep this simple acceptation, and add a new keyword for defining the input viewport. Have you looked at the Stretch option on say the NeoMagic driver ? I have a 1024x768 laptop display, and by default (ie unless I use option noStretch) all modes are stretched to fill the screen. Thus the modes (and modelines) describe the viewport size, not the output resolution. Interesting, i suppose the scaling is also done in the driver then, i will have a look at how it works when i get some free time. I wonder how the driver knows what the laptop display size is ? do you specify or does the monitor tell the driver about it with ddc ? The driver gets it from the graphics chip. DDC info on these systems comes from an external mointor if one is connected. DDC for the builtin screen does not exist. -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge [EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Xterm, Xft and line spacing
On Thu, Mar 06, 2003 at 08:55:45PM -0800, Keith Packard wrote: Around 23 o'clock on Mar 6, David Dawes wrote: I'm looking for as many rows as I can get in a given xterm size with a readable font, so I'd like to get rid of that unused white space. I tried a few things, and found that setting the font height to ascent + descent instead of what Xft reports as the height solves this. The height in the XftFont structure is the line spacing defined by the font designer as stored in the font itself, and often includes more spacing than is strictly necessary. Font designers are generally more concerned about readability than density. As a result, Xft provides an option to ignore the font's specified height and use the ascent+descent instead: $ xterm -fa monospace-11:minspace=true Thanks Keith. That does the trick. David -- David Dawes Release Engineer/Architect The XFree86 Project www.XFree86.org/~dawes ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: nasty little bug in radeon driver
... Now it works for me. Thanks, I've committed your fix to the CVS. Quick question -- I posed a patch to xc/programs/Xserver/hw/xfree86/os-support/bsd/alpha_video.c on Monday which makes X build properly on FreeBSD alpha - I asked if there were a better way to submit patches and I'm still wondering if I need to do something to get this patch accepted and put in... I've checked via cvsweb and the cvs repository doesn't have my patch... Is there someone in particular that I should contact about the patch? Fred Clift ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: nasty little bug in radeon driver
send it to [EMAIL PROTECTED] and/or [EMAIL PROTECTED] Alex --- [EMAIL PROTECTED] wrote: ... Now it works for me. Thanks, I've committed your fix to the CVS. Quick question -- I posed a patch to xc/programs/Xserver/hw/xfree86/os-support/bsd/alpha_video.c on Monday which makes X build properly on FreeBSD alpha - I asked if there were a better way to submit patches and I'm still wondering if I need to do something to get this patch accepted and put in... I've checked via cvsweb and the cvs repository doesn't have my patch... Is there someone in particular that I should contact about the patch? Fred Clift ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel __ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Multiple video consoles
On Fre, 2003-03-07 at 14:48, Dr Andrew C Aitchison wrote: On Fri, 7 Mar 2003, Sven Luther wrote: I wonder how the driver knows what the laptop display size is ? do you specify or does the monitor tell the driver about it with ddc ? The driver gets it from the graphics chip. DDC info on these systems comes from an external mointor if one is connected. DDC for the builtin screen does not exist. It does here. There are other methods to fall back to though. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
