Hard code some MFi controller devices instead of dynamically managing HID vs GameController.framework On pre-BigSur operating systems, dynamically answering whether we should use HID or GCF is intractable. Therefore we should just hard code devices we think it's important for GCF to handle, and use HID for the others.
<rdar://problem/65961406>
I have this in progress, will wait on https://bugs.webkit.org/show_bug.cgi?id=214188 to land so we can keep testing with future changes
<rdar://problem/65961432>
Created attachment 405187 [details] Patch
Created attachment 405188 [details] Patch
Created attachment 405190 [details] Patch
Created attachment 405191 [details] Patch
Comment on attachment 405191 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=405191&action=review Vast majority of this is a rs (test code) > Source/WebCore/platform/gamepad/cocoa/GameControllerGamepadProvider.mm:42 > +bool GameControllerGamepadProvider::willHandleVendorAndProduct(uint16_t vendorID, uint16_t productID) Allow me to register my objection at this code living in WebKit :D > Source/WebCore/platform/gamepad/mac/HIDGamepadProvider.mm:206 > + CFNumberGetValue(cfVendorID, kCFNumberIntType, &vendorID); > + CFNumberGetValue(cfProductID, kCFNumberIntType, &productID); Please don't use this; toll-free bridge to NSNumber and use the not-scary API. Even though it's fine in this case, it's nonideal to promote the dangerous one by using it.
(In reply to Tim Horton from comment #8) > Comment on attachment 405191 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=405191&action=review > > Vast majority of this is a rs (test code) > > > Source/WebCore/platform/gamepad/cocoa/GameControllerGamepadProvider.mm:42 > > +bool GameControllerGamepadProvider::willHandleVendorAndProduct(uint16_t vendorID, uint16_t productID) > > Allow me to register my objection at this code living in WebKit :D Noted. Your objection is second behind mine. Can't wait to remove it. > > Source/WebCore/platform/gamepad/mac/HIDGamepadProvider.mm:206 > > + CFNumberGetValue(cfVendorID, kCFNumberIntType, &vendorID); > > + CFNumberGetValue(cfProductID, kCFNumberIntType, &productID); > > Please don't use this; toll-free bridge to NSNumber and use the not-scary > API. Even though it's fine in this case, it's nonideal to promote the > dangerous one by using it. Done.
Created attachment 405208 [details] Patch for landing
Committed r264874: <https://trac.webkit.org/changeset/264874> All reviewed patches have been landed. Closing bug and clearing flags on attachment 405208 [details].
There were some build fixes for open source Catalina builders. Namely: https://trac.webkit.org/changeset/264881 https://trac.webkit.org/changeset/264883 https://trac.webkit.org/changeset/264884 https://trac.webkit.org/changeset/264885 https://trac.webkit.org/changeset/264886 https://trac.webkit.org/changeset/264887 https://trac.webkit.org/changeset/264888 (Can we get Catalina EWS plz?)