lkml.org 
[lkml]   [2014]   [Aug]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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


\
 
 \ /
  Last update: 2014-08-20 16:41    [W:0.065 / U:1.544 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site