On Thu, Apr 15, 2010 at 03:53:53PM +0200, Roman Fietze wrote:
> Hello Bill,
>
> On Thursday 15 April 2010 15:01:59 Bill Gatliff wrote:
>
> > Are you talking about this code here?
> >
> > void
> > shadowUpdatePacked (ScreenPtr pScreen,
> > shadowBufPtr pBuf)
> >
On Fre, 2010-04-16 at 08:14 +0200, Roman Fietze wrote:
>
> On Thursday 15 April 2010 18:07:03 Bill Gatliff wrote:
>
> > I would love it if you posted your code! Thanks!!
>
> In this source file I just added my own routines:
>
> Index: programs/Xserver/hw/xfree86/drivers/fbdev/fbdev.c
> ===
Hello Bill,
On Friday 16 April 2010 04:51:38 Bill Gatliff wrote:
> Apparently, there are several similar modifications that need to be
> made, ...
I'm SW-Engineer, so I assume HW, that's always a good bet. ;)
Please take care, that I forgot to tell you that my X server runs well
on a Futjitsu 8
Hello Bill,
On Thursday 15 April 2010 18:07:03 Bill Gatliff wrote:
> I would love it if you posted your code! Thanks!!
In this source file I just added my own routines:
Index: programs/Xserver/hw/xfree86/drivers/fbdev/fbdev.c
===
-
Hello Bill,
On Thursday 15 April 2010 22:14:09 Bill Gatliff wrote:
> I'm not sure what the *Weak stuff is doing. Can I just hack
> shadowUpdatePacked() itself?
I think so. But take care if you want to use that code on other
systems or without shadowfb. If I search for shadowUpdatePacked, then
I'
Roman Fietze wrote:
> Yes. I added a routine like
>
> /* Swap frame buffer bytes in 32 bit value. */
> static __inline unsigned int
> fbbits_swap32(unsigned int __bsx)
> {
> return __bsx) & 0xff00) >> 8) | (((__bsx) & 0x00ff) << 8) |
> (((__bsx) & 0xff00) >> 8) | (((_
Roman Fietze wrote:
> Then I added void shadowUpdatePackedSwapped16() and
> shadowUpdatePackedSwapped32() which I was using instead of the
> original *Weak functions, which in turn uses the above swap routine
> when copying from shadow to the device.
>
I'm not sure what the *Weak stuff is doing
I would love it if you posted your code! Thanks!!
b.g.
On Apr 15, 2010 8:53 AM, "Roman Fietze" wrote:
Hello Bill,
On Thursday 15 April 2010 15:01:59 Bill Gatliff wrote:
> Are you talking about this code here?
>
...
Yes. I added a routine like
/* Swap frame buffer bytes in 32 bit value. */
Hello Bill,
On Thursday 15 April 2010 15:01:59 Bill Gatliff wrote:
> Are you talking about this code here?
>
> void
> shadowUpdatePacked (ScreenPtr pScreen,
> shadowBufPtr pBuf)
> {
> ...
> while (i--)
> *win++ =
Roman Fietze wrote:
> Hallo Bill,
>
> On Thursday 15 April 2010 05:07:08 Bill Gatliff wrote:
>
>
>> Actually, I *have* Debian squeeze's xorg running on the platform just
>> fine, with a 2.6.34-rc1 kernel (kernel.org). Problem is, every single
>> diagonal line is very blocky--- not smooth at all
On Wed, 14 Apr 2010 22:07:08 -0500
Bill Gatliff wrote:
> Put simply, I have an MPC5200b platform with a Fujitsu "Lime" GDC, and
> I'm trying to run Debian squeeze's xorg on it.
>
> Actually, I *have* Debian squeeze's xorg running on the platform just
> fine, with a 2.6.34-rc1 kernel (kernel.org)
Hallo Bill,
On Thursday 15 April 2010 05:07:08 Bill Gatliff wrote:
> Actually, I *have* Debian squeeze's xorg running on the platform just
> fine, with a 2.6.34-rc1 kernel (kernel.org). Problem is, every single
> diagonal line is very blocky--- not smooth at all.
I'm 95% sure it's an endianess
On Wed, 2010-04-14 at 22:07 -0500, Bill Gatliff wrote:
>
> Anyone have any suggestions on where to start with this one? Anyone
> else running a similar configuration with any success? I'm completely
> lost, and running out of hair *fast*...
Most probably endian bugs in the Lime driver ...
Chee
Guys:
I'm not quite sure where to ask this question, but all my attempts
elsewhere have come up short, so...
Put simply, I have an MPC5200b platform with a Fujitsu "Lime" GDC, and
I'm trying to run Debian squeeze's xorg on it.
Actually, I *have* Debian squeeze's xorg running on the platform jus
14 matches
Mail list logo
