Messages in this thread | | | Date | Wed, 20 Aug 2014 16:27:19 +0200 | From | Andreas Mohr <> | Subject | Re: [PATCH 1/2] SOUND: kill gameport bits |
| |
Hi,
Sorry for having introduced a cut in discussion threading (broken formatting which caused In-Reply-To header loss).
Will add several slightly disconnected items in single mail due to restricted environment.
On Wed, Aug 20, 2014 at 08:09:49AM +0200, Takashi Iwai wrote: > 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: > > > 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.
BTW, I have a slightly extended vested interest in that topic since I did initial joystick driver support on Wine, too... (Read: there is the possibility of using many Windows apps with their joystick support, too - not to mention the various arcade emulators which probably have that as well).
> > > 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.
He probably meant one issue filed about this problem here: "Direct use of tsc: Analog joystick doesn't work properly with CPU frequency scaling activated" https://bugzilla.kernel.org/show_bug.cgi?id=12297 right?
> Hm, can't we just use the standard ktime for measuring the time diff? > And, I guess only few programs care the speed parameter.
For clocksource matters, I've got an initial patch for Azt3328 which adds its 1MHz timer as a clocksource, which probably means that on this hardware the gameport would be accurate for both digital and non-digital modes (not that that would help much for machines without this soundcard which also don't sport a high-res timer...).
Since I've got some more patches waiting for some gameport compatible soundcard devices, I should be able to take this opportunity to retest gameport support, too... And since there's in fact my VIA system which has my second azt3328 in its single-slot PCI and which in fact probably is a cpufreq system, I might be able to work on fixing the cpufreq timer issue (but if Vojtech managed to golden his offer to work on a fix to this issue, I would be far from unhappy :).
BTW, I think I spotted a bug in the gameport removal commit (one driver did an if (!joystick) ... where the subsequent line was removed as well even though logically it quite likely shouldn't).
From my POV it would be much more favourable to do this relatively simple(??) timer fix rather than removing an entire subsystem since it's partially(?) broken.
Andreas Mohr
| |