At Tue, 19 Aug 2014 22:18:15 -0700, Dmitry Torokhov wrote: > > Hi Andreas, > > On Wed, Aug 20, 2014 at 04:46:38AM +0200, Andreas Mohr wrote: > > > Hi, > > > > > Gameport support hasn't been working well ever since cpufreq became > > > mainstream and it becomes increasingly hard to find hardware and > > > software > > > that would run on such old hardware. > > > > Given that I'm puzzled why one would want to deprecate a whole subsystem > > which appears to be supported by a whole 14 different PCI sound card > > drivers (where the ones I'm owning hardware of are intended to be in > > active maintenance) > > Are you actively testing gameport interfaces with real joysticks/gamepads on > these cards? And what software is still in use that runs on these old boxes > (with mainline kernel)? MPlayer and some programs have the joystick interface (even often activated as default), IIRC. I don't use it. But I tested it sometime ago. > > and only 3 ISA-based ones, I'm missing several > > details and justifications of that decision here (perhaps there was a > > prior discussion/activity that I'm missing?). > > There was a post to linux-input a few days ago when I ased if anyone woudl cry > over gameport going away. Well, asking the usage in the devel ML isn't enough, I'm afraid. ML is only for a small group of developers, where no user cares unless they hit a problem. > > Also, I'm left wondering why e.g. my Athlon XP system (a very popular > > choice for longer times) would be affected by Cpufreq... > > And there are no details on how exactly cpufreq is a problem or how this > > timing issue could be fixed... > > If you take a look at gameport_measure_speed() in gameport.c you will see that > it counts cycles for timing, which obviously does not work that well when CPU > frequency changes. > > The bugs have been opened in bugzilla/reported on lists ages ago but nobody > stepped up to fix that. Hm, can't we just use the standard ktime for measuring the time diff? And, I guess only few programs care the speed parameter. > > The obvious workaround for such an ensuing dearth of hardware support > > could be USB 15-pin gameport adapters - but are they even supported on > > Linux? Haven't seen info on this... > > And even if supported, these adapters (at least the non-perfect ones, as > > can be seen from reviews on a well-known online shop site) are said to > > be hit-or-miss. > > > > http://www.flightsim.com/vbfs/showthread.php?238938-joystick-GamePort-to-USB-adapter-question > > http://reviews.thesource.ca/9026/2600164/nexxtech-usb-gameport-adapter-reviews/reviews.htm > > > > They have better chance of being supported ;) I had a couple a few years back > and they did work for me. > > > If we keep removing functionality like this, then why stop short of > > removing x86 32bit as a whole? By having Linux support nicely restricted > > to hardware made within the last 5 years, we would surely be doing the > > planned-obsolescence Micro$oft "ecosystem" (what was ecological about > > this again?) a huge favour... > > I really do not care about Microsoft and favors, I just go by the fact that > this hardware is becoming naturally extinct. And not only hardware, but also > software that uses it. Do you still play a lot of games with joysticks on such > hardware? IMO, the number of users is less relevant for such an action. Even if there're only a few users, users do exist. But, if the code maintenance becomes a too big burden, it's time to think of code removal. Is this the case? Really difficult to keep the code? Last but not least, the usual steps for such a big deprecation is to disable the build in Kconfig at first, watch out for a couple of release cycles, then drop the actual codes. Dropping the whole stuff from the beginning is too risky, especially if there is no alternative. thanks, Takashi -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
