Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SDL_DisplayYUVOverlay() doesn't clip to the screen area #50

SDLBugzilla opened this issue Feb 10, 2021 · 1 comment

SDL_DisplayYUVOverlay() doesn't clip to the screen area #50

SDLBugzilla opened this issue Feb 10, 2021 · 1 comment


Copy link

This bug report was migrated from our old Bugzilla tracker.

Reported in version: don't know
Reported for operating system, platform: All, All

Comments on the original bug report:

On 2006-03-31 01:11:37 +0000, Sam Lantinga wrote:

Date: Wed, 29 Mar 2006 12:38:27 -0500
From: "Shane M. Walton"
Subject: Re: [SDL] SDL_DisplayYUVOverlay() segmentation fault

I wanted to add some information and rephrase my question.

The testoverlay.c and testoverlay2.c fail when the SDL_Rect.x/y != 0.
The following occurs:

Created 64x88X3 software YV12 overlay
X Error failed request: BadValue (integer parameter out of range for
Major opcode of failed request: 145 (MIT-SHM)
Minor opcode of failed request: 3 (X_ShmPutImage)
Value in failed request: 0x1b8
Serial number of failed request: 40
Current serial number in output stream: 41

On 2006-04-17 01:40:18 +0000, Sam Lantinga wrote:

This is fixed in CVS.

On 2006-04-17 01:56:37 +0000, Sam Lantinga wrote:

Actually, this is active for all overlay drivers.

On 2006-04-17 02:46:47 +0000, Sam Lantinga wrote:

The clipping is done at a higher level, and the low level functions are
passed clipped rectangles. Drivers which don't support source clipping
have not been changed, so the image will be squished instead of clipped,
but at least they will no longer crash when the destination rect was out
of bounds.

Copy link

I'am having the same problem, whenever a save the SDL_surface it saves a black image

madebr pushed a commit to madebr/SDL that referenced this issue Mar 19, 2023
Co-authored-by: renovate[bot] <29139614+renovate[bot]>
Wohlstand pushed a commit to Wohlstand/SDL that referenced this issue Mar 21, 2024
With the previous logic, the first GameCube controller was given the
product ID 0x0000, which might be used as a special value in some

With this change the first GameCube controller is given the product ID
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
None yet

No branches or pull requests

2 participants