linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Bill Gatliff <bgat@billgatliff.com>
To: Roman Fietze <roman.fietze@telemotive.de>
Cc: linuxppc-dev@lists.ozlabs.org
Subject: Re: Xorg on Fujitsu "Lime" with MPC5200b?
Date: Thu, 15 Apr 2010 21:51:38 -0500	[thread overview]
Message-ID: <4BC7D0BA.5000502@billgatliff.com> (raw)
In-Reply-To: <201004151553.53426.roman.fietze@telemotive.de>

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) & 0xff000000) >> 8) | (((__bsx) & 0x00ff0000) << 8) |
> 	    (((__bsx) & 0x0000ff00) >> 8) | (((__bsx) & 0x000000ff) << 8));
> }
>   

I baked the above code into shadowUpdatePacked(), and it didn't seem to
help anything--- my icewm mouse cursor was still quite jagged, as was
all the text on the screen (clock widget, etc).  So I replaced the above
code with a return 0, and the icewm desktop went completely black--- and
everything else remained unchanged.

Apparently, there are several similar modifications that need to be
made, i.e. the shadowUpdatePacked() function isn't the only way to the
framebuffer memory?  I'm really looking forward to seeing your code, as
I have no idea how to even identify the places that need hacking.  I
understand the utility of the hack, however.

Makes me think that we're all just soldering this chip down to the wrong
data lines, and makes me wonder if there isn't an "endianness bit" in
the memory bus controller that can undo this damage for us.  I know I've
seen such a bit in other SoCs...


Thanks!


b.g.

-- 
Bill Gatliff
bgat@billgatliff.com

  parent reply	other threads:[~2010-04-16  2:50 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-15  3:07 Xorg on Fujitsu "Lime" with MPC5200b? Bill Gatliff
2010-04-15  4:53 ` Benjamin Herrenschmidt
2010-04-15  7:21 ` Roman Fietze
2010-04-15 13:01   ` Bill Gatliff
2010-04-15 13:53     ` Roman Fietze
     [not found]       ` <v2ma0706c7b1004150906p34b853a0r80e2bb751e034b97@mail.gmail.com>
2010-04-15 16:07         ` Bill Gatliff
2010-04-16  6:14           ` Roman Fietze
2010-04-16  8:30             ` Michel Dänzer
2010-04-15 20:14       ` Bill Gatliff
2010-04-16  5:48         ` Roman Fietze
2010-04-16  2:51       ` Bill Gatliff [this message]
2010-04-16  8:28         ` Roman Fietze
2010-04-16  9:25       ` Gabriel Paubert
2010-04-15  7:44 ` Anatolij Gustschin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4BC7D0BA.5000502@billgatliff.com \
    --to=bgat@billgatliff.com \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=roman.fietze@telemotive.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).