Skip to content

modesetting: byte-swap ARGB cursor uploads on big-endian#2196

Open
metux wants to merge 1 commit intorelease/25.0from
pr/25.0/modesetting-byte-swap-argb-cursor-uploads-on-big-endian-_2026-04-13_12-44-04
Open

modesetting: byte-swap ARGB cursor uploads on big-endian#2196
metux wants to merge 1 commit intorelease/25.0from
pr/25.0/modesetting-byte-swap-argb-cursor-uploads-on-big-endian-_2026-04-13_12-44-04

Conversation

@metux
Copy link
Copy Markdown
Contributor

@metux metux commented Apr 13, 2026

@metux metux added this to the 25.0.x bugfix milestone Apr 13, 2026
@metux metux self-assigned this Apr 13, 2026
@metux metux requested a review from a team April 13, 2026 10:44
@stefan11111
Copy link
Copy Markdown
Contributor

stefan11111 commented Apr 13, 2026

@metux Could you prefix backports to release branches with something in the title, so it's easier to see what goes into master, and what goes into releases?

For this patch in particular, I have the same question I asked upstream:
https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2156

I guess cpu_to_le actually means cpu_to_gpu?
Or is there some spec that I'm not aware of, that says the cursor buffer is always le?

When I'll port this to master, I wonder if we should do something like this once when first setting the cursor:

volatile CARD32* ind = (volatile CARD32*)map;
volatile CARD32* outd = (volatile CARD32*)map;

*ind = 0x01020304;

switch (*outd) {
case 0x01020304:
    /* le */
    /* fast memcpy path */
case 0x04030201:
    /* be */
    /* Slow for + swap path */
default:
    /* other (pdp endian?) */
    /* soft cursor */
}

@metux metux force-pushed the pr/25.0/modesetting-byte-swap-argb-cursor-uploads-on-big-endian-_2026-04-13_12-44-04 branch from d5bc6aa to 7c65dc5 Compare April 17, 2026 16:52
@metux
Copy link
Copy Markdown
Contributor Author

metux commented Apr 17, 2026

@metux Could you prefix backports to release branches with something in the title, so it's easier to see what goes into master, and what goes into releases?

Good idea. I'll check how to add that to my MPBT tooling.

I guess cpu_to_le actually means cpu_to_gpu?
Or is there some spec that I'm not aware of, that says the cursor buffer is always le?

Well, I haven't seen any GPU operating in BE yet - so I'd assume they're all in LE (otherwise we already would have needed some extra swapping for those).

But i'm open to renaming this macro to something like cpu_to_gpu().

When I'll port this to master, I wonder if we should do something like this once when first setting the cursor:

volatile CARD32* ind = (volatile CARD32*)map;
volatile CARD32* outd = (volatile CARD32*)map;

*ind = 0x01020304;

switch (*outd) {
case 0x01020304:
    /* le */
    /* fast memcpy path */
case 0x04030201:
    /* be */
    /* Slow for + swap path */
default:
    /* other (pdp endian?) */
    /* soft cursor */
}

IMHO, that wouldn't tell us whether GPU is operating in opposite endian. Just detecting corrupt BUS link or GPU memory.

@stefan11111
Copy link
Copy Markdown
Contributor

Well, I haven't seen any GPU operating in BE yet - so I'd assume they're all in LE (otherwise we already would have needed some extra swapping for those).

Guess it's probably fine then.
The reason this raised some alarm bells is this:

  │ CONFIG_FB_FOREIGN_ENDIAN:                                                                                                                                                                                                              │
  │                                                                                                                                                                                                                                        │
  │ This menu will let you enable support for the framebuffers with                                                                                                                                                                        │
  │ non-native endianness (e.g. Little-Endian framebuffer on a                                                                                                                                                                             │
  │ Big-Endian machine). Most probably you don't have such hardware,                                                                                                                                                                       │
  │ so it's safe to say "n" here.                                                                                                                                                                                                          │
  │                                                                                                                                                                                                                                        │
  │ Symbol: FB_FOREIGN_ENDIAN [=n]                                                                                                                                                                                                         │
  │ Type  : bool                                                                                                                                                                                                                           │
  │ Defined at drivers/video/fbdev/core/Kconfig:115                                                                                                                                                                                        │
  │   Prompt: Framebuffer foreign endianness support                                                                                                                                                                                       │
  │   Depends on: HAS_IOMEM [=y] && FB [=y]                                                                                                                                                                                                │
  │   Location:                                                                                                                                                                                                                            │
  │     -> Device Drivers                                                                                                                                                                                                                  │
  │       -> Graphics support                                                                                                                                                                                                              │
  │         -> Frame buffer Devices                                                                                                                                                                                                        │
  │           -> Framebuffer foreign endianness support (FB_FOREIGN_ENDIAN [=n])                                                                                                                                                           │
  │ Selected by [n]:                                                                                                                                                                                                                       │
  │   - FB_MB862XX_LIME [=n] && HAS_IOMEM [=y] && FB_MB862XX [=n] && OF [=n] && PPC

If the default kernel config usually forbids different endianness between cpu and gpu, I assumed there were some be machines with be gpu's.

But i'm open to renaming this macro to something like cpu_to_gpu().

No need, if it's doing cpu_to_le, then let it be named cpu_to_le, though perhaps if would be worth adding a comment that we really want cpu_to_gpu?

IMHO, that wouldn't tell us whether GPU is operating in opposite endian. Just detecting corrupt BUS link or GPU memory.

Oops, you're right :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants