We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 4744 - libudev fallback when failing to load library
Summary: libudev fallback when failing to load library
Status: WAITING
Alias: None
Product: SDL
Classification: Unclassified
Component: joystick (show other bugs)
Version: HG 2.1
Hardware: x86_64 Linux
: P2 normal
Assignee: tomwardio
QA Contact: Sam Lantinga
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-07-29 15:09 UTC by tomwardio
Modified: 2019-11-11 20:21 UTC (History)
2 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description tomwardio 2019-07-29 15:09:37 UTC 
Currently if we build SDL2 with libudev support, if a client's machine (for whatever reason) cannot load/install libudev, SDL2 will fail to run. From what I gather, it should be possible to fallback to the non-udev methods for both joystick and haptic feedback rather than returning an Init error, would this be acceptable?

If application authors do want to hard fail on libudev not being available, this could be added as an optional flag.

Happy to implement this, but wanted to sound this out before sending patch :)

Thanks!

tom
Comment 1 Sam Lantinga 2019-07-29 20:52:18 UTC 
Yes, that sounds good.

Thanks!
Comment 2 Ryan C. Gordon 2019-07-30 17:49:37 UTC 
(Sorry if you get several emails like this, we're marking a bunch of bugs.)

We're hoping to ship SDL 2.0.11 on a much shorter timeframe than we have historically done releases, so I'm starting to tag bugs we hope to have closed in this release cycle.

Note that this tag means we just intend to scrutinize this bug for the 2.0.11 release: we may fix it, reject it, or even push it back to a later release for now, but this helps give us both a goal and a wishlist for the next release.

If this bug has been quiet for a few months and you have new information (such as, "this is definitely still broken" or "this got fixed at some point"), please feel free to retest and/or add more notes to the bug.

--ryan.
Comment 3 Ryan C. Gordon 2019-09-20 20:47:36 UTC 
We're changing how we do SDL release versions; now releases will be even numbers (2.0.10, 2.0.12, etc), and as soon as we tag a release, we'll move the internal version number to an odd number (2.0.12 ships, we tag the latest in revision control as 2.0.13 immediately, which will become 2.0.14 on release, etc).

As such, I'm moving the bugs tagged with target-2.0.11 to target 2.0.12. Sorry if you get a lot of email from this change!

Thanks,
--ryan.
Comment 4 Ryan C. Gordon 2019-09-20 20:48:42 UTC 
We're changing how we do SDL release versions; now releases will be even numbers (2.0.10, 2.0.12, etc), and as soon as we tag a release, we'll move the internal version number to an odd number (2.0.12 ships, we tag the latest in revision control as 2.0.13 immediately, which will become 2.0.14 on release, etc).

As such, I'm moving the bugs tagged with target-2.0.11 to target 2.0.12. Sorry if you get a lot of email from this change!

Thanks,
--ryan.
Comment 5 Ryan C. Gordon 2019-10-27 05:12:35 UTC 
It's worth noting that at least src/core/linux/SDL_evdev.c has this comment:

    #else
            /* TODO: Scan the devices manually, like a caveman */
    #endif /* SDL_USE_LIBUDEV */


...which is to say, not everything has existing fallback code for non-UDEV systems.

(these fallbacks, if written, should _never_ deal with hotplugging, imho. They should just find what's available at startup and be done with it. If the device tree changes and they want SDL to notice: they should install UDEV. Also, if they want to deal with anything other than the most standard device layout with no surprises: they should install UDEV. But I can definitely see a value for low-complexity embedded systems here.)

--ryan.
Comment 6 Ryan C. Gordon 2019-11-11 20:21:18 UTC 
I still think this is worth doing (whether Tom does it or I do it), but I'm going to remove the target-2.0.12 keyword for now, as this can wait for a later release.

--ryan.