Message-ID: <s5hwqa3hetu.wl-tiwai@suse.de>
Date:	Wed, 20 Aug 2014 08:09:49 +0200
From:	Takashi Iwai <tiwai@...e.de>
To:	Dmitry Torokhov <dmitry.torokhov@...il.com>
Cc:	Andreas Mohr <andi@...as.de>, linux-input@...r.kernel.org,
	linux-kernel@...r.kernel.org, Vojtech Pavlik <vojtech@...e.cz>,
	Jiri Kosina <jkosina@...e.cz>
Subject: Re: [PATCH 1/2] SOUND: kill gameport bits

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-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists