RE: Will the behaviors of XFree86 be effected by different kernel?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi:
It seems an alignment issue that causes this problem.
In our driver, we will reset the base address relate to destination y while
the value of y is over some value. And the text will be normal if I fix the
base address as the original value.
Would you please tell me how you know the bug is coming from we incorrectly
sets the HARDWARE_PATTERN_SCREEN_ORIGIN. Is there any log file I can read or
some message printed from XAA will notice me?
 
Appreciate your help,
cckuo
.


-----Original Message-----
From: Mark Vojkovich [mailto:mvojkovi@xxxxxxxxxxx] 
Sent: Monday, September 11, 2006 3:17 AM
To: cckuo
Cc: xfree86@xxxxxxxxxxx
Subject: RE:  Will the behaviors of XFree86 be effected by
different kernel?



On Mon, 11 Sep 2006, cckuo wrote:

> HI:
> After reading the HOWTO file, would you please help me to clarify some
> questions about the meaning of the parameters that XAA pass to me?
> (To minimize the difference, suppose all the flags I used below are
> HARDWARE_PATTERN_SCREEN_ORIGIN | HARDWARE_PATTERN_PROGRAMMED_BITS
> 1. What is the unit of (x,y) that pass by Subsequent function, bytes or
> pixels? Since I have seen (0x312, 0x812) in hex pass to driver while my
> resolution is (0x400, 0x300) in hex, that is (1024x768)?

   The XAA interface is always in pixels.  If (0x312, 0x812) is
the (x,y) then this is rendering offscreen to an offscreen pixmap
or to the pixmap cache.


> 2. Does HARDWARE_PATTERN_SCREEN_ORIGIN means the all the value of (x,y)
that
> pass subsequently are relative to upper-left corner of my on-screen
memory,
> that is, if on-screen is located from the physical memory, 0xd0000000, and
> (x,y) is (0x10, 0), the destination address that HW should put the pattern
> on after ropping is 0xd0000020, assuming the (x,y) is in pixel unit and
the
> screen depth is 16bpp. Is that right ?


   All x,y coordinates are relative to the upper-left of the on-screen
memory in ALL cases.  HARDWARE_PATTERN_SCREEN_ORIGIN refers to the
source pattern alignment.  It means the phase of the 8x8 pattern
should be specified relative to the screen origin.  Without that option
it is relative to the origin of the rectangle being drawn.  We are
passing an 8x8 pattern to the hardware.  If you want the first pixel
in the pattern to correspond to the first pixel of the rectangle
being drawn, then you do NOT want HARDWARE_PATTERN_SCREEN_ORIGIN to
be set.  Most hardware actually need the pattern specified relative
to the origin of the surface being drawn on not the origin of the
rectangle being drawn.

   At typical rendering case is where XAA needs to fill a large area
with an 8x8 pattern but the destination is clipped by various
occluding windows so the area ends up being filled with lots of
smaller operations.  If the pattern is specified relative to the
destination surface then the pattern only needs to be specified
once.  If the pattern needs to be specified relative to each
individual rectangle, then XAA needs to realign the 8x8 pattern
for each rectangle.  That is what happens when
HARDWARE_PATTERN_SCREEN_ORIGIN
is not set.  A new realigned pattern is passed to the driver
for every Subsequent call.


			Mark.


>
> Thanks for your help.
> cckuo
>
> >   The fail_pattern.jpg looks like the driver incorrectly sets
> >the HARDWARE_PATTERN_SCREEN_ORIGIN flag.   See section 2.6 of
> >xc/programs/Xserver/hw/xfree86/xaa/XAA.HOWTO
> >
> >       Mark.
>
>
>
>

_______________________________________________
XFree86 mailing list
XFree86@xxxxxxxxxxx
http://XFree86.Org/mailman/listinfo/xfree86

[Index of Archives]     [X Forum]     [Xorg]     [XFree86 Newbie]     [IETF Announce]     [Security]     [Font Config]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux Kernel]

  Powered by Linux