Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
This is fantastic!

Please make a tree, I would like to try that out.
How should I get it to you? I've just got it on my drive, I could tar up the cocoa folder, that's all that's needed.

Ok...attached a zip of it. A diff will show my minimal changes.

A few of the driver funcs still aren't quite right, so needs a little more work.
 

Attachments

  • cocoa.zip
    54.1 KB · Views: 6
How should I get it to you? I've just got it on my drive, I could tar up the cocoa folder, that's all that's needed.

Ok...attached a zip of it. A diff will show my minimal changes.

It will probably be helpful to do this via git, that would ensure that I do not mess anything up by an incorrect diffing. (Provided it is convenient for you, of course.)

(I will make the new diff.)
 
Last edited:
P. S. Let me rather make a diff against the exact version rather than the branch, otherwise it fails to apply.
 
It will probably be helpful to do this via git, that would ensure that I do not mess anything up by an incorrect diffing. (Provided it is convenient for you, of course.)

This is the current diff with `release-2.32.x` upstream branch:
Oh geez. My git fu is very poor. You'll have to hold my cold little furry paw and help me, if you want me to do anything much. I've no idea how to reconcile the diff with my changes. I don't really care one way or the other, and it'd be good to learn.

I just based it off 2.32.4 because that was what I had handy. I can redo the fixes for any version you need. Just pick one so it's not a moving target!

Actually...it's likely you can just replace the entire "cocoa" folder in any 2.3x.x and it'll work. Oh...no...you don't want to do that...you want to diff against the latest whatever that might be, eh?
 
This is the correct diff against 2.32.4 release (of cocoa files).
 

Attachments

  • patch-Cocoa-fixes.txt
    294.8 KB · Views: 3
Oh geez. My git fu is very poor. You'll have to hold my cold little furry paw and help me, if you want me to do anything much. I've no idea how to reconcile the diff with my changes. I don't really care one way or the other, and it'd be good to learn.

I just based it off 2.32.4 because that was what I had handy. I can redo the fixes for any version you need. Just pick one so it's not a moving target!

Let’s do it the way it works better for you. There is no point to introduce an extra inconvenience. If you will think that using git may help your workflow, I can suggest how to do that. Otherwise I can handle generating patches, of course.
 
By the way, which config did you use? My port (X11-based) disables CoreAudio for Tiger, since that failed for me when I tried, and I never bothered trying to fix it. I do not have Tiger, so cannot check; on 10.5+ CoreAudio should work as-is.

Also, what OpenGL did you use? Apple libs from /usr/lib/X11?
 
Let’s do it the way it works better for you. There is no point to introduce an extra inconvenience. If you will think that using git may help your workflow, I can suggest how to do that. Otherwise I can handle generating patches, of course.
I still don't know what to do with the diff...as far as "workflow"...it'd be charitable to call what I do that. I just have a snapshot that worked with X11, and hacked cocoa on that. It's just files on the drive, a copy of the port from one point in time. Like I said, I can do a git clone of whatever and put my changes back on that, it's about a dozen little key tweaks. Or put what I have up on my own git and you could grab that and do the magic. It's all equally convenience and inconvenience to me!

./configure --disable-dbus \
--disable-esd \
--disable-libsamplerate \
--disable-pulseaudio \
--enable-video-cocoa \
--disable-video-wayland \
--disable-x11-shared \
--enable-video-x11 \
--x-includes=/usr/X11R6/include \
--x-libraries=/usr/X11R6/lib \
--disable-jack \
--disable-joystick \
--disable-audio \
--disable-haptic \
--disable-hidapi \
--disable-hidapi-joystick \
--disable-locale

I plan on looking at joystick and audio (on tiger in a recent 2.3x.x) one day, but no promises.
 
  • Like
Reactions: barracuda156
On 10.6 fails on this:
Code:
/opt/local/var/macports/build/_opt_local_ppcports_devel_libsdl2-cocoa/libsdl2-cocoa/work/SDL2-2.32.4/src/video/cocoa/SDL_cocoakeyboard.m: In function ‘UpdateKeymap’:
/opt/local/var/macports/build/_opt_local_ppcports_devel_libsdl2-cocoa/libsdl2-cocoa/work/SDL2-2.32.4/src/video/cocoa/SDL_cocoakeyboard.m:446: warning: ISO C90 forbids mixed declarations and code
/opt/local/var/macports/build/_opt_local_ppcports_devel_libsdl2-cocoa/libsdl2-cocoa/work/SDL2-2.32.4/src/video/cocoa/SDL_cocoakeyboard.m:481: error: too few arguments to function ‘SDL_SetKeymap’
 
I still don't know what to do with the diff...as far as "workflow"...it'd be charitable to call what I do that. I just have a snapshot that worked with X11, and hacked cocoa on that. It's just files on the drive, a copy of the port from one point in time. Like I said, I can do a git clone of whatever and put my changes back on that, it's about a dozen little key tweaks. Or put what I have up on my own git and you could grab that and do the magic. It's all equally convenience and inconvenience to me!

If you could clone SDL upstream, check-out to 2.32.x and apply your fixes on top of that, it will be easier to carry on, I think (whether for you or for whoever else).

I normally do the following:
– fork upstream;
– `git clone ${my_forked_repo_URL};
– cd to the local cloned repo;
– `git remote add upstream ${upstream_repo_URL}`;
– `git fetch upstream` (to have all branches);
– `git checkout ${upstream_branch_to_work_with}`;
– `git checkout -b ${my_branch_on_top_of_that};
– apply w/e changes I want;
– `git add .` (this add everything, included new files, or `git add -u` for changed files only);
– `git commit -m "Fix a broken thing"`;
– `git push origin ${my_branch_on_top_of_that}` (if I want to have the branch accessible);
– `git format-patch ${upstream_branch_to_work_with}` (this produces a diff file).

I plan on looking at joystick and audio (on tiger in a recent 2.3x.x) one day, but no promises.

To be clear, this is not a request from my side, personally I do not need joystick, and CoreAudio already works on 10.5–10.6. However, there are a lot of people who do care about games and use 10.4.
 
On 10.6 fails on this:
Code:
/opt/local/var/macports/build/_opt_local_ppcports_devel_libsdl2-cocoa/libsdl2-cocoa/work/SDL2-2.32.4/src/video/cocoa/SDL_cocoakeyboard.m: In function ‘UpdateKeymap’:
/opt/local/var/macports/build/_opt_local_ppcports_devel_libsdl2-cocoa/libsdl2-cocoa/work/SDL2-2.32.4/src/video/cocoa/SDL_cocoakeyboard.m:446: warning: ISO C90 forbids mixed declarations and code
/opt/local/var/macports/build/_opt_local_ppcports_devel_libsdl2-cocoa/libsdl2-cocoa/work/SDL2-2.32.4/src/video/cocoa/SDL_cocoakeyboard.m:481: error: too few arguments to function ‘SDL_SetKeymap’

It needs a 4th argument, since the function signature needs 4: https://github.com/libsdl-org/SDL/b...9655a494cd128/src/events/SDL_keyboard_c.h#L39

Current version of that line: https://github.com/libsdl-org/SDL/b...deo/cocoa/SDL_cocoakeyboard.m#L306C53-L306C63
 
Ok, first the keymap error doesn't show for me because it's inside a "#if defined(MAC_OS_X_VERSION_10_5)". It's likely that changing line 481 to "SDL_SetKeymap(0, keymap, SDL_NUM_SCANCODES,SDL_TRUE);" will build, if you really want to be crazy. (That may not be entirely correct, but it is what several of the other drivers do)

But enough spinning wheels.

Ok, your git suggestions look very good. I haven't done much forking, and haven't bothered doing much of anything with local copies except pushing my changes back up to my personal gits. (ie I don't bother with keeping track of my changes locally). If I forked the main SDL2, I 'd have to not just apply my recent fixes, but also the patches I got from the port, etc. I could do all that, but it would be a bit of a pain. I really SHOULD learn all that, and given time, will eventually, but if you want to test things before that, we should think of something else.

If there's a way you can tell me to how to grab an entire SDL2 tree that is currently working for you, whatever version, just the full source, remember this is on a machine without any macports at all, I can patch that and test it. Then you could diff and grab my changes that way.

As far as joystick and audio go, I fully understand. I would do it because I'm reasonably sure I can, and nobody else will bother!
 
If there's a way you can tell me to how to grab an entire SDL2 tree that is currently working for you, whatever version

Yeah, sure. Looks like my fork has up-to-date patches for SDL3 in the master: https://github.com/barracuda156/SDL
But let me make a new tree for SDL2.

You did not build cocoaopengles, right? It breaks down with a lot of errors, and the file had no patches. Or did we just miss fixes for it?
 
There didn't seem to be any cocoa gles stuff in the version of SDL 2.32.4 I had, which was originally from one of your ports. If you have an SDL2 with it in it, and can get it to me, I can take a look...and maybe just make sure it doesn't error out with #ifdef's on systems that have no gles.
 
There didn't seem to be any cocoa gles stuff in the version of SDL 2.32.4 I had, which was originally from one of your ports. If you have an SDL2 with it in it, and can get it to me, I can take a look...and maybe just make sure it doesn't error out with #ifdef's on systems that have no gles.

This: https://github.com/libsdl-org/SDL/b...a494cd128/src/video/cocoa/SDL_cocoaopengles.m (and corresponding header).
I did not remove it in my port, it probably is not compiled naturally on your machine, but was picked by default on mine. There is a flag to disable opengles explicitly.
 
`handleTouches` in `SDL_cocoawindow.m` misses an argument in `SDL_AddTouch`. You have enabled that part for 10.6+, so it is not seen on 10.4. If it can be supported, then we should add `devtype` back. If not, then disable for 10.6 too.

Also `SDL_SendTouch` same issue, `window` argument is missing.
 
@lauland Okay, I got it building with a very few extra fixes added (for the code which is not relevant for 10.4) and disabled Cocoa OpenGLES. Basically, I just restored original function signatures, so that arguments match to what the codebase expects.
I will try it working soon.
 
@lauland Okay, I got it building with a very few extra fixes added (for the code which is not relevant for 10.4) and disabled Cocoa OpenGLES. Basically, I just restored original function signatures, so that arguments match to what the codebase expects.
I will try it working soon.
Sounds good, I'm building it (from your repo as above) and will apply my fixes as needed. If we can actually get on the same tree, that'd rock!
 
  • Like
Reactions: barracuda156
Sounds good, I'm building it (from your repo as above) and will apply my fixes as needed. If we can actually get on the same tree, that'd rock!

If you use Apple X11, just drop X11 commit from there, since it switches to xorg-libX11 and mesa.
(`git revert ${commit_hash}` should work.)

BTW, does it make sense to enable Cocoa and X11 at the same time?
 
Ok, the cocoa driver in what I got from your git is VERY different from the 2.32.4 I was working on. I can give it a try, but am not sure if it will work.

Compare what was in the zip file I attached previously and you'll see wildly different files.

Update: No, it is just too new. I could do something eventually, but this is not the older version which was easily fixable.

(You can have multiple video drivers, and switch between them prob with an env var, tho I've never tried)
 
Ok, the cocoa driver in what I got from your git is VERY different from the 2.32.4 I was working on. I can give it a try, but am not sure if it will work.

Compare what was in the zip file I attached previously and you'll see wildly different files.

Update: No, it is just too new. I could do something eventually, but this is not the older version which was easily fixable.

(You can have multiple video drivers, and switch between them prob with an env var, tho I've never tried)

Ah, I did not know it deviated that much.

I will make a branch for 2.32.6 release, let’s make it easy now.
 
Maybe I need to enable OpenGL, as of now I can build against libsdl2-cocoa, but no graphic output: an app opens a back window (tried with lite-xl and grafx2).

P. S. Do you know some minimal-dependency app which uses SDL2 as a test ground?
 
Last edited:
Maybe I need to enable OpenGL, as of now I can build against libsdl2-cocoa, but no graphic output: an app opens a back window (tried with lite-xl and grafx2).

P. S. Do you know some minimal-dependency app which uses SDL2 as a test ground?
Ok...after a break, I consulted with one of my cats (she demanded attention, and to play), and came to this conclusion: It is not likely possible to easily fix any too recent "cocoa" folder to work. But...if you replace the ENTIRE cocoa folder, I can get the very old one to work with pretty much any SDL2 version. Yes, this is FAR from ideal, but it does work. I've had very good luck with doing entire drivers for classic MacOS and Amiga with the very latest SDL2.

I should have known there'd be just too many changes and not sure why I tried. With that said, I'll get the tree building and working on Tiger, with the ancient cocoa driver. I'll use the "original" SDL2 that I first pulled from the git you provided, and probably won't need the other one.

We'll run into things that are disabled when built on Tiger, like the Keymap thing, but will work them out one at a time. Once I have it working I can get the changes back to you via git, you can try a build, if it hitches, we'll fix it, etc. Like I said, far from ideal, but if you want cocoa, this is a semi-decent way to get it.

OpenGL should be enabled by default if you use a configure close to the one I quoted previously.

We won't have any of the newer stuff, such as gles/egl, so it is a non-issue.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.