Re: [PATCH 1/2] SOUND: kill gameport bits
On Thu, Aug 28, 2014 at 10:03:55PM +0200, Clemens Ladisch wrote: > Takashi Iwai wrote: > > did anyone test the patch at all...? > > Appears to work. The ymfpci gameport seems to be somewhat unreliable: > > analog.c: 100 out of 17347 reads (0%) on pci:06:06.1/gameport0 failed > analog.c: 122 out of reads (10%) on pci:06:07.0/gameport0 failed The analog.c gameport read routine is unreliable by design. The 558 chip is not an ADC, it's an one-shot timer from 1971. The analog position of the joystick is measured by timing bit changes on the gameport. analog.c does that without disabling interrupts, as the read can take several milliseconds. analog.c instead detects when an interrupt influenced the measurement too much and retries. The retries are counted and reported. 10% is a largeish number, but still something the analog.c driver can cope with and give reliable results. > There is still some dependence of the CPU speed on the loop counts > calculated by gameport_time(), but it's not very high; the following are > for 3200 and 800 MHz, 5 times each: > > gameport gameport7: EMU10K1 is pci:06:06.1/gameport0, io 0xe480, speed > 651kHz > gameport gameport8: EMU10K1 is pci:06:06.1/gameport0, io 0xe480, speed > 651kHz > gameport gameport9: EMU10K1 is pci:06:06.1/gameport0, io 0xe480, speed > 651kHz > gameport gameport10: EMU10K1 is pci:06:06.1/gameport0, io 0xe480, speed > 651kHz > gameport gameport11: EMU10K1 is pci:06:06.1/gameport0, io 0xe480, speed > 651kHz > gameport gameport12: EMU10K1 is pci:06:06.1/gameport0, io 0xe480, speed > 612kHz > gameport gameport13: EMU10K1 is pci:06:06.1/gameport0, io 0xe480, speed > 612kHz > gameport gameport14: EMU10K1 is pci:06:06.1/gameport0, io 0xe480, speed > 612kHz > gameport gameport15: EMU10K1 is pci:06:06.1/gameport0, io 0xe480, speed > 611kHz > gameport gameport16: EMU10K1 is pci:06:06.1/gameport0, io 0xe480, speed > 612kHz The gameport speed is speed of the i/o to the port. It may change as frequencies in the system change. It's used for timeouts on digital gameport protocols only and thus a variation of less than 20% shouldn't cause trouble. The analog.c driver uses its own timing calibration to make the analog_cooked_read() reliable even when the speed of the i/o operations changes. What is important is that the GET_TIME() macro is fast (0.1 usec or less), precise (sub-microsecond resolution) and reliable. Digital protocols also rely on udelay() and mdelay() waiting precisely for the amount of time specified. -- Vojtech Pavlik Director SuSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] SOUND: kill gameport bits
Takashi Iwai wrote: > did anyone test the patch at all...? Appears to work. The ymfpci gameport seems to be somewhat unreliable: analog.c: 100 out of 17347 reads (0%) on pci:06:06.1/gameport0 failed analog.c: 122 out of reads (10%) on pci:06:07.0/gameport0 failed There is still some dependence of the CPU speed on the loop counts calculated by gameport_time(), but it's not very high; the following are for 3200 and 800 MHz, 5 times each: gameport gameport7: EMU10K1 is pci:06:06.1/gameport0, io 0xe480, speed 651kHz gameport gameport8: EMU10K1 is pci:06:06.1/gameport0, io 0xe480, speed 651kHz gameport gameport9: EMU10K1 is pci:06:06.1/gameport0, io 0xe480, speed 651kHz gameport gameport10: EMU10K1 is pci:06:06.1/gameport0, io 0xe480, speed 651kHz gameport gameport11: EMU10K1 is pci:06:06.1/gameport0, io 0xe480, speed 651kHz gameport gameport12: EMU10K1 is pci:06:06.1/gameport0, io 0xe480, speed 612kHz gameport gameport13: EMU10K1 is pci:06:06.1/gameport0, io 0xe480, speed 612kHz gameport gameport14: EMU10K1 is pci:06:06.1/gameport0, io 0xe480, speed 612kHz gameport gameport15: EMU10K1 is pci:06:06.1/gameport0, io 0xe480, speed 611kHz gameport gameport16: EMU10K1 is pci:06:06.1/gameport0, io 0xe480, speed 612kHz Regards, Clemens -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] SOUND: kill gameport bits
Takashi Iwai wrote: did anyone test the patch at all...? Appears to work. The ymfpci gameport seems to be somewhat unreliable: analog.c: 100 out of 17347 reads (0%) on pci:06:06.1/gameport0 failed analog.c: 122 out of reads (10%) on pci:06:07.0/gameport0 failed There is still some dependence of the CPU speed on the loop counts calculated by gameport_time(), but it's not very high; the following are for 3200 and 800 MHz, 5 times each: gameport gameport7: EMU10K1 is pci:06:06.1/gameport0, io 0xe480, speed 651kHz gameport gameport8: EMU10K1 is pci:06:06.1/gameport0, io 0xe480, speed 651kHz gameport gameport9: EMU10K1 is pci:06:06.1/gameport0, io 0xe480, speed 651kHz gameport gameport10: EMU10K1 is pci:06:06.1/gameport0, io 0xe480, speed 651kHz gameport gameport11: EMU10K1 is pci:06:06.1/gameport0, io 0xe480, speed 651kHz gameport gameport12: EMU10K1 is pci:06:06.1/gameport0, io 0xe480, speed 612kHz gameport gameport13: EMU10K1 is pci:06:06.1/gameport0, io 0xe480, speed 612kHz gameport gameport14: EMU10K1 is pci:06:06.1/gameport0, io 0xe480, speed 612kHz gameport gameport15: EMU10K1 is pci:06:06.1/gameport0, io 0xe480, speed 611kHz gameport gameport16: EMU10K1 is pci:06:06.1/gameport0, io 0xe480, speed 612kHz Regards, Clemens -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] SOUND: kill gameport bits
On Thu, Aug 28, 2014 at 10:03:55PM +0200, Clemens Ladisch wrote: Takashi Iwai wrote: did anyone test the patch at all...? Appears to work. The ymfpci gameport seems to be somewhat unreliable: analog.c: 100 out of 17347 reads (0%) on pci:06:06.1/gameport0 failed analog.c: 122 out of reads (10%) on pci:06:07.0/gameport0 failed The analog.c gameport read routine is unreliable by design. The 558 chip is not an ADC, it's an one-shot timer from 1971. The analog position of the joystick is measured by timing bit changes on the gameport. analog.c does that without disabling interrupts, as the read can take several milliseconds. analog.c instead detects when an interrupt influenced the measurement too much and retries. The retries are counted and reported. 10% is a largeish number, but still something the analog.c driver can cope with and give reliable results. There is still some dependence of the CPU speed on the loop counts calculated by gameport_time(), but it's not very high; the following are for 3200 and 800 MHz, 5 times each: gameport gameport7: EMU10K1 is pci:06:06.1/gameport0, io 0xe480, speed 651kHz gameport gameport8: EMU10K1 is pci:06:06.1/gameport0, io 0xe480, speed 651kHz gameport gameport9: EMU10K1 is pci:06:06.1/gameport0, io 0xe480, speed 651kHz gameport gameport10: EMU10K1 is pci:06:06.1/gameport0, io 0xe480, speed 651kHz gameport gameport11: EMU10K1 is pci:06:06.1/gameport0, io 0xe480, speed 651kHz gameport gameport12: EMU10K1 is pci:06:06.1/gameport0, io 0xe480, speed 612kHz gameport gameport13: EMU10K1 is pci:06:06.1/gameport0, io 0xe480, speed 612kHz gameport gameport14: EMU10K1 is pci:06:06.1/gameport0, io 0xe480, speed 612kHz gameport gameport15: EMU10K1 is pci:06:06.1/gameport0, io 0xe480, speed 611kHz gameport gameport16: EMU10K1 is pci:06:06.1/gameport0, io 0xe480, speed 612kHz The gameport speed is speed of the i/o to the port. It may change as frequencies in the system change. It's used for timeouts on digital gameport protocols only and thus a variation of less than 20% shouldn't cause trouble. The analog.c driver uses its own timing calibration to make the analog_cooked_read() reliable even when the speed of the i/o operations changes. What is important is that the GET_TIME() macro is fast (0.1 usec or less), precise (sub-microsecond resolution) and reliable. Digital protocols also rely on udelay() and mdelay() waiting precisely for the amount of time specified. -- Vojtech Pavlik Director SuSE Labs -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] SOUND: kill gameport bits
At Sun, 24 Aug 2014 07:07:16 +0200,
Andreas Mohr wrote:
>
> On Thu, Aug 21, 2014 at 01:29:03PM +0200, Takashi Iwai wrote:
> > I did a quick hack and it seems working on my box.
> > The patch is below.
>
> Thanks!!
>
> Further comments below.
>
> I will be testing this ASAP.
> > +static bool use_ktime = true;
> > +module_param(use_ktime, bool, 0400);
>
> Towards final commit, should probably add param docs on what may be switched
> here and why.
>
> > +
> > /*
> > * gameport_mutex protects entire gameport subsystem and is taken
> > * every time gameport port or driver registrered or unregistered.
> > @@ -76,6 +80,36 @@ static unsigned int get_time_pit(void)
> >
> > static int gameport_measure_speed(struct gameport *gameport)
> > {
> > + unsigned int i, t, tx;
> > + u64 t1, t2;
> > + unsigned long flags;
> > +
> > + if (gameport_open(gameport, NULL, GAMEPORT_MODE_RAW))
> > + return 0;
> > +
> > + tx = ~0;
> > +
> > + for (i = 0; i < 50; i++) {
> > + local_irq_save(flags);
> > + t1 = ktime_get_ns();
> > + for (t = 0; t < 50; t++)
> > + gameport_read(gameport);
> > + t2 = ktime_get_ns();
> > + local_irq_restore(flags);
> > + udelay(i * 10);
> > + if (t2 - t1 < tx)
> > + tx = t2 - t1;
>
> This impl is not doing the more complex t3, t2, t1 calculation
> that the PIT impl is doing (likely for the uncommented purpose
> of eliminating timer I/O delay from timing consideration).
> Do/don't ktime/TSC impls better need such an I/O timing correction,
> or are they so fast relative to gameport I/O delays
> that it does not matter? (probably the case for TSC at least).
It's based on x86-64 implementation that doesn't take t3 into
account. I don't think it doesn't matter so much on the recent
systems, but certainly it can't hurt to measure it, too.
> Oh, and any reason that such a speed calculation remains painfully duplicated
> in both source files? That's possibly done for layering reasons,
> but I'd have to analyze it further.
Yeah, a layer should be one reason. Another reason is that TSC read
has to be a macro, thus you'd need anyway reimplementation, either
static inline or such.
In my patch, I didn't want to change too much in a shot. It just adds
the replacement using ktime, that's all. If you'd like to work on
this further, feel free to do it.
> > +static inline u64 get_time(void)
> > +{
> > + if (use_ktime) {
> > + return ktime_get_ns();
> > + } else {
> > + unsigned int x;
> > + GET_TIME(x);
> > + return x;
> > + }
> > +}
>
> It might be useful to have a first commit to introduce these helpers,
> and a second commit to then add ktime support (to keep review code size
> down).
The very purpose of this helper is for ktime. For TSC, the helper
*is* GET_TIME(). So, splitting commit without introducing ktime
doesn't make much sense.
Nevertheless: did anyone test the patch at all...?
thanks,
Takashi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] SOUND: kill gameport bits
At Sun, 24 Aug 2014 07:07:16 +0200,
Andreas Mohr wrote:
On Thu, Aug 21, 2014 at 01:29:03PM +0200, Takashi Iwai wrote:
I did a quick hack and it seems working on my box.
The patch is below.
Thanks!!
Further comments below.
I will be testing this ASAP.
+static bool use_ktime = true;
+module_param(use_ktime, bool, 0400);
Towards final commit, should probably add param docs on what may be switched
here and why.
+
/*
* gameport_mutex protects entire gameport subsystem and is taken
* every time gameport port or driver registrered or unregistered.
@@ -76,6 +80,36 @@ static unsigned int get_time_pit(void)
static int gameport_measure_speed(struct gameport *gameport)
{
+ unsigned int i, t, tx;
+ u64 t1, t2;
+ unsigned long flags;
+
+ if (gameport_open(gameport, NULL, GAMEPORT_MODE_RAW))
+ return 0;
+
+ tx = ~0;
+
+ for (i = 0; i 50; i++) {
+ local_irq_save(flags);
+ t1 = ktime_get_ns();
+ for (t = 0; t 50; t++)
+ gameport_read(gameport);
+ t2 = ktime_get_ns();
+ local_irq_restore(flags);
+ udelay(i * 10);
+ if (t2 - t1 tx)
+ tx = t2 - t1;
This impl is not doing the more complex t3, t2, t1 calculation
that the PIT impl is doing (likely for the uncommented purpose
of eliminating timer I/O delay from timing consideration).
Do/don't ktime/TSC impls better need such an I/O timing correction,
or are they so fast relative to gameport I/O delays
that it does not matter? (probably the case for TSC at least).
It's based on x86-64 implementation that doesn't take t3 into
account. I don't think it doesn't matter so much on the recent
systems, but certainly it can't hurt to measure it, too.
Oh, and any reason that such a speed calculation remains painfully duplicated
in both source files? That's possibly done for layering reasons,
but I'd have to analyze it further.
Yeah, a layer should be one reason. Another reason is that TSC read
has to be a macro, thus you'd need anyway reimplementation, either
static inline or such.
In my patch, I didn't want to change too much in a shot. It just adds
the replacement using ktime, that's all. If you'd like to work on
this further, feel free to do it.
+static inline u64 get_time(void)
+{
+ if (use_ktime) {
+ return ktime_get_ns();
+ } else {
+ unsigned int x;
+ GET_TIME(x);
+ return x;
+ }
+}
It might be useful to have a first commit to introduce these helpers,
and a second commit to then add ktime support (to keep review code size
down).
The very purpose of this helper is for ktime. For TSC, the helper
*is* GET_TIME(). So, splitting commit without introducing ktime
doesn't make much sense.
Nevertheless: did anyone test the patch at all...?
thanks,
Takashi
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] SOUND: kill gameport bits
On Thu, Aug 21, 2014 at 01:29:03PM +0200, Takashi Iwai wrote:
> I did a quick hack and it seems working on my box.
> The patch is below.
Thanks!!
Further comments below.
I will be testing this ASAP.
> +static bool use_ktime = true;
> +module_param(use_ktime, bool, 0400);
Towards final commit, should probably add param docs on what may be switched
here and why.
> +
> /*
> * gameport_mutex protects entire gameport subsystem and is taken
> * every time gameport port or driver registrered or unregistered.
> @@ -76,6 +80,36 @@ static unsigned int get_time_pit(void)
>
> static int gameport_measure_speed(struct gameport *gameport)
> {
> + unsigned int i, t, tx;
> + u64 t1, t2;
> + unsigned long flags;
> +
> + if (gameport_open(gameport, NULL, GAMEPORT_MODE_RAW))
> + return 0;
> +
> + tx = ~0;
> +
> + for (i = 0; i < 50; i++) {
> + local_irq_save(flags);
> + t1 = ktime_get_ns();
> + for (t = 0; t < 50; t++)
> + gameport_read(gameport);
> + t2 = ktime_get_ns();
> + local_irq_restore(flags);
> + udelay(i * 10);
> + if (t2 - t1 < tx)
> + tx = t2 - t1;
This impl is not doing the more complex t3, t2, t1 calculation
that the PIT impl is doing (likely for the uncommented purpose
of eliminating timer I/O delay from timing consideration).
Do/don't ktime/TSC impls better need such an I/O timing correction,
or are they so fast relative to gameport I/O delays
that it does not matter? (probably the case for TSC at least).
Oh, and any reason that such a speed calculation remains painfully duplicated
in both source files? That's possibly done for layering reasons,
but I'd have to analyze it further.
> +static inline u64 get_time(void)
> +{
> + if (use_ktime) {
> + return ktime_get_ns();
> + } else {
> + unsigned int x;
> + GET_TIME(x);
> + return x;
> + }
> +}
It might be useful to have a first commit to introduce these helpers,
and a second commit to then add ktime support (to keep review code size
down).
Thanks,
Andreas Mohr
--
GNU/Linux. It's not the software that's free, it's you.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] SOUND: kill gameport bits
On Thu, Aug 21, 2014 at 01:29:03PM +0200, Takashi Iwai wrote:
I did a quick hack and it seems working on my box.
The patch is below.
Thanks!!
Further comments below.
I will be testing this ASAP.
+static bool use_ktime = true;
+module_param(use_ktime, bool, 0400);
Towards final commit, should probably add param docs on what may be switched
here and why.
+
/*
* gameport_mutex protects entire gameport subsystem and is taken
* every time gameport port or driver registrered or unregistered.
@@ -76,6 +80,36 @@ static unsigned int get_time_pit(void)
static int gameport_measure_speed(struct gameport *gameport)
{
+ unsigned int i, t, tx;
+ u64 t1, t2;
+ unsigned long flags;
+
+ if (gameport_open(gameport, NULL, GAMEPORT_MODE_RAW))
+ return 0;
+
+ tx = ~0;
+
+ for (i = 0; i 50; i++) {
+ local_irq_save(flags);
+ t1 = ktime_get_ns();
+ for (t = 0; t 50; t++)
+ gameport_read(gameport);
+ t2 = ktime_get_ns();
+ local_irq_restore(flags);
+ udelay(i * 10);
+ if (t2 - t1 tx)
+ tx = t2 - t1;
This impl is not doing the more complex t3, t2, t1 calculation
that the PIT impl is doing (likely for the uncommented purpose
of eliminating timer I/O delay from timing consideration).
Do/don't ktime/TSC impls better need such an I/O timing correction,
or are they so fast relative to gameport I/O delays
that it does not matter? (probably the case for TSC at least).
Oh, and any reason that such a speed calculation remains painfully duplicated
in both source files? That's possibly done for layering reasons,
but I'd have to analyze it further.
+static inline u64 get_time(void)
+{
+ if (use_ktime) {
+ return ktime_get_ns();
+ } else {
+ unsigned int x;
+ GET_TIME(x);
+ return x;
+ }
+}
It might be useful to have a first commit to introduce these helpers,
and a second commit to then add ktime support (to keep review code size
down).
Thanks,
Andreas Mohr
--
GNU/Linux. It's not the software that's free, it's you.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] SOUND: kill gameport bits
At Wed, 20 Aug 2014 09:05:58 +0200,
Takashi Iwai wrote:
>
> > > > > 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?
> >
> > We could use high-res timers, if they are available. Are they available on
> > such
> > old hardware and are they sufficiently fast to provide needed timings? I
> > definitely do not have any hardware to est with.
>
> The boards aren't necessarily bound with the old hardware. PCI boards
> run fine on the modern machines if they still have a PCI slot (how
> lucky). And, the highres timer itself isn't so new...
I did a quick hack and it seems working on my box.
The patch is below.
thanks,
Takashi
-- 8< --
From: Takashi Iwai
Subject: [PATCH] Input: joystick - Use ktime for measuring timing
The current codes in gameport and analog joystick drivers for the time
accounting have a long-standing problem when the system is running
with CPU freq; since the timing is measured via TSC or sample counter,
the calculation isn't reliable.
In this patch, as a simple fix, use the standard ktime to measure the
timing. In case where no high resolution timer is available,
use_ktime bool option is provided to both modules. Setting
use_ktime=false switches to the old methods.
Signed-off-by: Takashi Iwai
---
drivers/input/gameport/gameport.c | 38 -
drivers/input/joystick/analog.c | 70 ---
2 files changed, 88 insertions(+), 20 deletions(-)
diff --git a/drivers/input/gameport/gameport.c
b/drivers/input/gameport/gameport.c
index 24c41ba7d4e0..48d91f12e397 100644
--- a/drivers/input/gameport/gameport.c
+++ b/drivers/input/gameport/gameport.c
@@ -23,6 +23,7 @@
#include
#include/* HZ */
#include
+#include
/*#include */
@@ -30,6 +31,9 @@ MODULE_AUTHOR("Vojtech Pavlik ");
MODULE_DESCRIPTION("Generic gameport layer");
MODULE_LICENSE("GPL");
+static bool use_ktime = true;
+module_param(use_ktime, bool, 0400);
+
/*
* gameport_mutex protects entire gameport subsystem and is taken
* every time gameport port or driver registrered or unregistered.
@@ -76,6 +80,36 @@ static unsigned int get_time_pit(void)
static int gameport_measure_speed(struct gameport *gameport)
{
+ unsigned int i, t, tx;
+ u64 t1, t2;
+ unsigned long flags;
+
+ if (gameport_open(gameport, NULL, GAMEPORT_MODE_RAW))
+ return 0;
+
+ tx = ~0;
+
+ for (i = 0; i < 50; i++) {
+ local_irq_save(flags);
+ t1 = ktime_get_ns();
+ for (t = 0; t < 50; t++)
+ gameport_read(gameport);
+ t2 = ktime_get_ns();
+ local_irq_restore(flags);
+ udelay(i * 10);
+ if (t2 - t1 < tx)
+ tx = t2 - t1;
+ }
+
+ gameport_close(gameport);
+ t = 100 * 50;
+ if (tx)
+ t /= tx;
+ return t;
+}
+
+static int old_gameport_measure_speed(struct gameport *gameport)
+{
#if defined(__i386__)
unsigned int i, t, t1, t2, t3, tx;
@@ -521,7 +555,9 @@ static void gameport_add_port(struct gameport *gameport)
if (gameport->parent)
gameport->parent->child = gameport;
- gameport->speed = gameport_measure_speed(gameport);
+ gameport->speed = use_ktime ?
+ gameport_measure_speed(gameport) :
+ old_gameport_measure_speed(gameport);
list_add_tail(>node, _list);
diff --git a/drivers/input/joystick/analog.c b/drivers/input/joystick/analog.c
index ab0fdcd36e18..723276d40b58 100644
--- a/drivers/input/joystick/analog.c
+++ b/drivers/input/joystick/analog.c
@@ -36,6 +36,7 @@
#include
#include
#include
+#include
#define DRIVER_DESC"Analog joystick and gamepad driver"
@@ -43,6 +44,9 @@ MODULE_AUTHOR("Vojtech Pavlik ");
MODULE_DESCRIPTION(DRIVER_DESC);
MODULE_LICENSE("GPL");
+static bool use_ktime = true;
+module_param(use_ktime, bool, 0400);
+
/*
* Option parsing.
*/
@@ -171,6 +175,25 @@ static unsigned long analog_faketime = 0;
#warning Precise timer not defined for this architecture.
#endif
+static inline u64 get_time(void)
+{
+ if (use_ktime) {
+ return ktime_get_ns();
+ } else {
+ unsigned int x;
+ GET_TIME(x);
+ return x;
+
Re: [PATCH 1/2] SOUND: kill gameport bits
Hi Dmitry,
On Wed, Aug 20, 2014 at 4:49 PM, Dmitry Torokhov
wrote:
> On Wed, Aug 20, 2014 at 02:15:30PM +0200, Takashi Iwai wrote:
>> At Wed, 20 Aug 2014 09:05:58 +0200,
>> Takashi Iwai wrote:
>> > Well, it worked on my test machine a year ago or so. Maybe I had a
>> > good luck.
>>
>> FYI, now I tested again an analog joystick on SB Live put on a Dell
>> IvyBridge desktop with 3.17-rc1 x86-64 kernel, and it worked fine as
>> is.
>>
>> So it's not that broken.
>
> That's probably because in your system TSCs are stable when switching CPU
> frequency. Earlier systems had bunch of issues there IIRC.
>From the success stories above, it seems gameport doesn't work on only
a limited number of systems.
Perhaps the subsystem can fail with a big fat warning at runtime if such
a system is detected?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] SOUND: kill gameport bits
Hi Dmitry,
On Wed, Aug 20, 2014 at 4:49 PM, Dmitry Torokhov
dmitry.torok...@gmail.com wrote:
On Wed, Aug 20, 2014 at 02:15:30PM +0200, Takashi Iwai wrote:
At Wed, 20 Aug 2014 09:05:58 +0200,
Takashi Iwai wrote:
Well, it worked on my test machine a year ago or so. Maybe I had a
good luck.
FYI, now I tested again an analog joystick on SB Live put on a Dell
IvyBridge desktop with 3.17-rc1 x86-64 kernel, and it worked fine as
is.
So it's not that broken.
That's probably because in your system TSCs are stable when switching CPU
frequency. Earlier systems had bunch of issues there IIRC.
From the success stories above, it seems gameport doesn't work on only
a limited number of systems.
Perhaps the subsystem can fail with a big fat warning at runtime if such
a system is detected?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] SOUND: kill gameport bits
At Wed, 20 Aug 2014 09:05:58 +0200,
Takashi Iwai wrote:
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?
We could use high-res timers, if they are available. Are they available on
such
old hardware and are they sufficiently fast to provide needed timings? I
definitely do not have any hardware to est with.
The boards aren't necessarily bound with the old hardware. PCI boards
run fine on the modern machines if they still have a PCI slot (how
lucky). And, the highres timer itself isn't so new...
I did a quick hack and it seems working on my box.
The patch is below.
thanks,
Takashi
-- 8 --
From: Takashi Iwai ti...@suse.de
Subject: [PATCH] Input: joystick - Use ktime for measuring timing
The current codes in gameport and analog joystick drivers for the time
accounting have a long-standing problem when the system is running
with CPU freq; since the timing is measured via TSC or sample counter,
the calculation isn't reliable.
In this patch, as a simple fix, use the standard ktime to measure the
timing. In case where no high resolution timer is available,
use_ktime bool option is provided to both modules. Setting
use_ktime=false switches to the old methods.
Signed-off-by: Takashi Iwai ti...@suse.de
---
drivers/input/gameport/gameport.c | 38 -
drivers/input/joystick/analog.c | 70 ---
2 files changed, 88 insertions(+), 20 deletions(-)
diff --git a/drivers/input/gameport/gameport.c
b/drivers/input/gameport/gameport.c
index 24c41ba7d4e0..48d91f12e397 100644
--- a/drivers/input/gameport/gameport.c
+++ b/drivers/input/gameport/gameport.c
@@ -23,6 +23,7 @@
#include linux/workqueue.h
#include linux/sched.h /* HZ */
#include linux/mutex.h
+#include linux/timekeeping.h
/*#include asm/io.h*/
@@ -30,6 +31,9 @@ MODULE_AUTHOR(Vojtech Pavlik vojt...@ucw.cz);
MODULE_DESCRIPTION(Generic gameport layer);
MODULE_LICENSE(GPL);
+static bool use_ktime = true;
+module_param(use_ktime, bool, 0400);
+
/*
* gameport_mutex protects entire gameport subsystem and is taken
* every time gameport port or driver registrered or unregistered.
@@ -76,6 +80,36 @@ static unsigned int get_time_pit(void)
static int gameport_measure_speed(struct gameport *gameport)
{
+ unsigned int i, t, tx;
+ u64 t1, t2;
+ unsigned long flags;
+
+ if (gameport_open(gameport, NULL, GAMEPORT_MODE_RAW))
+ return 0;
+
+ tx = ~0;
+
+ for (i = 0; i 50; i++) {
+ local_irq_save(flags);
+ t1 = ktime_get_ns();
+ for (t = 0; t 50; t++)
+ gameport_read(gameport);
+ t2 = ktime_get_ns();
+ local_irq_restore(flags);
+ udelay(i * 10);
+ if (t2 - t1 tx)
+ tx = t2 - t1;
+ }
+
+ gameport_close(gameport);
+ t = 100 * 50;
+ if (tx)
+ t /= tx;
+ return t;
+}
+
+static int old_gameport_measure_speed(struct gameport *gameport)
+{
#if defined(__i386__)
unsigned int i, t, t1, t2, t3, tx;
@@ -521,7 +555,9 @@ static void gameport_add_port(struct gameport *gameport)
if (gameport-parent)
gameport-parent-child = gameport;
- gameport-speed = gameport_measure_speed(gameport);
+ gameport-speed = use_ktime ?
+ gameport_measure_speed(gameport) :
+ old_gameport_measure_speed(gameport);
list_add_tail(gameport-node, gameport_list);
diff --git a/drivers/input/joystick/analog.c b/drivers/input/joystick/analog.c
index ab0fdcd36e18..723276d40b58 100644
--- a/drivers/input/joystick/analog.c
+++ b/drivers/input/joystick/analog.c
@@ -36,6 +36,7 @@
#include linux/gameport.h
#include linux/jiffies.h
#include linux/timex.h
+#include linux/timekeeping.h
#define DRIVER_DESCAnalog joystick and gamepad driver
@@ -43,6 +44,9 @@ MODULE_AUTHOR(Vojtech Pavlik vojt...@ucw.cz);
MODULE_DESCRIPTION(DRIVER_DESC);
MODULE_LICENSE(GPL);
+static bool use_ktime = true;
+module_param(use_ktime, bool, 0400);
+
/*
* Option parsing.
*/
@@ -171,6 +175,25 @@ static unsigned long analog_faketime = 0;
#warning Precise timer not defined for this architecture.
#endif
+static inline u64 get_time(void)
+{
+ if (use_ktime) {
+ return ktime_get_ns();
+ } else
Re: [PATCH 1/2] SOUND: kill gameport bits
On Wed, Aug 20, 2014 at 02:15:30PM +0200, Takashi Iwai wrote: > At Wed, 20 Aug 2014 09:05:58 +0200, > Takashi Iwai wrote: > > Well, it worked on my test machine a year ago or so. Maybe I had a > > good luck. > > FYI, now I tested again an analog joystick on SB Live put on a Dell > IvyBridge desktop with 3.17-rc1 x86-64 kernel, and it worked fine as > is. > > So it's not that broken. That's probably because in your system TSCs are stable when switching CPU frequency. Earlier systems had bunch of issues there IIRC. Thanks. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] SOUND: kill gameport bits
On Wed, Aug 20, 2014 at 04:27:19PM +0200, Andreas Mohr wrote: > > > > 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? Right. There is also about a3d joystick not workign and I think a few others. > > > 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. Fair enough. If you send me patches that fixes issues then I do not see any problem with it staying in. Vojtech also promised to dig out his old hardware. Thanks. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] SOUND: kill gameport bits
On Wed, Aug 20, 2014 at 2:29 PM, One Thousand Gnomes
wrote:
>> It's the gameport core code that is currently broken under some
>> situation, right? If so, marking it as broken is the first step, and
>> we don't need to touch else. We may fix it later, or we may not. If
>> the thing isn't improved, then we can drop the whole stuff.
>
> It's only broken on x86 with frequency changing. x86 is not the only
> platform with ISA or PCI bus or gameports.
>
> It really ought to go via staging, and the other arch maintainers be
> asked. The m68k and mips world does include a department of relics and
> retro-computing 8)
It seems there are no m68k-specific drivers with gameport support...
Good, let's kill all joystick ports that are newer than ports with 2600-style
connectors ;-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] SOUND: kill gameport bits
> It's the gameport core code that is currently broken under some > situation, right? If so, marking it as broken is the first step, and > we don't need to touch else. We may fix it later, or we may not. If > the thing isn't improved, then we can drop the whole stuff. It's only broken on x86 with frequency changing. x86 is not the only platform with ISA or PCI bus or gameports. It really ought to go via staging, and the other arch maintainers be asked. The m68k and mips world does include a department of relics and retro-computing 8) I suspect nobody cares however. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] SOUND: kill gameport bits
> It wouldn't be hard to fix: That code was developed when the timing > infrastructure in the kernel was non-existent, making use of it today > would make things a lot easier. You can also use pm_qos on most machines to stop PM messing it up. Ugly but works. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] SOUND: kill gameport bits
At Wed, 20 Aug 2014 09:05:58 +0200, Takashi Iwai wrote: > Well, it worked on my test machine a year ago or so. Maybe I had a > good luck. FYI, now I tested again an analog joystick on SB Live put on a Dell IvyBridge desktop with 3.17-rc1 x86-64 kernel, and it worked fine as is. So it's not that broken. Takashi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] SOUND: kill gameport bits
Dmitry Torokhov wrote: > Gameport support hasn't been working well ever since cpufreq became > mainstream Back in the gameport-mainstream days, we did not have a usable high- resolution timer API. But why can't we use something like getrawmonotonic() now? (Yes, I'm volunteering ...) > and it becomes increasingly hard to find hardware and software that > would run on such old hardware. I have two such sound cards, and a joystick. Regards, Clemens -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] SOUND: kill gameport bits
At Tue, 19 Aug 2014 23:31:30 -0700, Dmitry Torokhov wrote: > > 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: > > > > > > > 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. > > But we are not dropping joystick support, you can still use USB, BT, etc > joysticks. It is only gameport joysticks that I think are pretty much extinct > by now. They are dying, I agree. But is it really extinct? It's hard to judge. > > > > 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. > > That is true, but what is better venue? Even disabling in Kconfig won't help > much as distros will re-enable it and users do not compile their own kernels. I meant to statically disable Kconfig, or just "depends on BROKEN". Only user who edits Kconfig and build the kernel can enable it again. > > > > 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? > > We could use high-res timers, if they are available. Are they available on > such > old hardware and are they sufficiently fast to provide needed timings? I > definitely do not have any hardware to est with. The boards aren't necessarily bound with the old hardware. PCI boards run fine on the modern machines if they still have a PCI slot (how lucky). And, the highres timer itself isn't so new... > > And, I guess only few programs care the speed parameter. > > It is not programs that care about speed parameter, it is joystick kernel > drivers that need it to time access. OK. > > > > 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,
Re: [PATCH 1/2] SOUND: kill gameport bits
On Tue, Aug 19, 2014 at 10:18:15PM -0700, Dmitry Torokhov wrote: > 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)? I still do have a huge box of gameport hardware in my office, it's just that I haven't opened it for a number of years. However, if this thread spurred enough interest in gameport devices, I would be willing to open it and do the needed fixes. If not, I think dropping makes sense. I still would shed a tear for all those weird devices in the box, and possibly design an ATMega-based USB<->Gameport adapter that actually works and supports even the digital joysticks. > > 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. It wouldn't be hard to fix: That code was developed when the timing infrastructure in the kernel was non-existent, making use of it today would make things a lot easier. > > 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. They do work for analog joysticks if you don't want any extended functionality. I have a couple in said box. -- Vojtech Pavlik Director SuSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] SOUND: kill gameport bits
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: > > > > > 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. But we are not dropping joystick support, you can still use USB, BT, etc joysticks. It is only gameport joysticks that I think are pretty much extinct by now. > > > > 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. That is true, but what is better venue? Even disabling in Kconfig won't help much as distros will re-enable it and users do not compile their own kernels. > > > > 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? We could use high-res timers, if they are available. Are they available on such old hardware and are they sufficiently fast to provide needed timings? I definitely do not have any hardware to est with. > And, I guess only few programs care the speed parameter. It is not programs that care about speed parameter, it is joystick kernel drivers that need it to time access. > > > > > 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? We can keep it, but it is pretty much broken, so why? Thanks. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] SOUND: kill gameport bits
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: 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. But we are not dropping joystick support, you can still use USB, BT, etc joysticks. It is only gameport joysticks that I think are pretty much extinct by now. 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. That is true, but what is better venue? Even disabling in Kconfig won't help much as distros will re-enable it and users do not compile their own kernels. 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? We could use high-res timers, if they are available. Are they available on such old hardware and are they sufficiently fast to provide needed timings? I definitely do not have any hardware to est with. And, I guess only few programs care the speed parameter. It is not programs that care about speed parameter, it is joystick kernel drivers that need it to time access. 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? We can keep it, but it is pretty much broken, so why? Thanks. -- Dmitry -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] SOUND: kill gameport bits
On Tue, Aug 19, 2014 at 10:18:15PM -0700, Dmitry Torokhov wrote: 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)? I still do have a huge box of gameport hardware in my office, it's just that I haven't opened it for a number of years. However, if this thread spurred enough interest in gameport devices, I would be willing to open it and do the needed fixes. If not, I think dropping makes sense. I still would shed a tear for all those weird devices in the box, and possibly design an ATMega-based USB-Gameport adapter that actually works and supports even the digital joysticks. 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. It wouldn't be hard to fix: That code was developed when the timing infrastructure in the kernel was non-existent, making use of it today would make things a lot easier. 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. They do work for analog joysticks if you don't want any extended functionality. I have a couple in said box. -- Vojtech Pavlik Director SuSE Labs -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] SOUND: kill gameport bits
At Tue, 19 Aug 2014 23:31:30 -0700, Dmitry Torokhov wrote: 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: 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. But we are not dropping joystick support, you can still use USB, BT, etc joysticks. It is only gameport joysticks that I think are pretty much extinct by now. They are dying, I agree. But is it really extinct? It's hard to judge. 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. That is true, but what is better venue? Even disabling in Kconfig won't help much as distros will re-enable it and users do not compile their own kernels. I meant to statically disable Kconfig, or just depends on BROKEN. Only user who edits Kconfig and build the kernel can enable it again. 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? We could use high-res timers, if they are available. Are they available on such old hardware and are they sufficiently fast to provide needed timings? I definitely do not have any hardware to est with. The boards aren't necessarily bound with the old hardware. PCI boards run fine on the modern machines if they still have a PCI slot (how lucky). And, the highres timer itself isn't so new... And, I guess only few programs care the speed parameter. It is not programs that care about speed parameter, it is joystick kernel drivers that need it to time access. OK. 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? We can keep it, but it is pretty much broken, so why? Well, it worked on my test machine a year ago or so. Maybe I had a good
Re: [PATCH 1/2] SOUND: kill gameport bits
Dmitry Torokhov wrote: Gameport support hasn't been working well ever since cpufreq became mainstream Back in the gameport-mainstream days, we did not have a usable high- resolution timer API. But why can't we use something like getrawmonotonic() now? (Yes, I'm volunteering ...) and it becomes increasingly hard to find hardware and software that would run on such old hardware. I have two such sound cards, and a joystick. Regards, Clemens -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] SOUND: kill gameport bits
At Wed, 20 Aug 2014 09:05:58 +0200, Takashi Iwai wrote: Well, it worked on my test machine a year ago or so. Maybe I had a good luck. FYI, now I tested again an analog joystick on SB Live put on a Dell IvyBridge desktop with 3.17-rc1 x86-64 kernel, and it worked fine as is. So it's not that broken. Takashi -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] SOUND: kill gameport bits
It wouldn't be hard to fix: That code was developed when the timing infrastructure in the kernel was non-existent, making use of it today would make things a lot easier. You can also use pm_qos on most machines to stop PM messing it up. Ugly but works. Alan -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] SOUND: kill gameport bits
It's the gameport core code that is currently broken under some situation, right? If so, marking it as broken is the first step, and we don't need to touch else. We may fix it later, or we may not. If the thing isn't improved, then we can drop the whole stuff. It's only broken on x86 with frequency changing. x86 is not the only platform with ISA or PCI bus or gameports. It really ought to go via staging, and the other arch maintainers be asked. The m68k and mips world does include a department of relics and retro-computing 8) I suspect nobody cares however. Alan -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] SOUND: kill gameport bits
On Wed, Aug 20, 2014 at 2:29 PM, One Thousand Gnomes
gno...@lxorguk.ukuu.org.uk wrote:
It's the gameport core code that is currently broken under some
situation, right? If so, marking it as broken is the first step, and
we don't need to touch else. We may fix it later, or we may not. If
the thing isn't improved, then we can drop the whole stuff.
It's only broken on x86 with frequency changing. x86 is not the only
platform with ISA or PCI bus or gameports.
It really ought to go via staging, and the other arch maintainers be
asked. The m68k and mips world does include a department of relics and
retro-computing 8)
It seems there are no m68k-specific drivers with gameport support...
Good, let's kill all joystick ports that are newer than ports with 2600-style
connectors ;-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] SOUND: kill gameport bits
On Wed, Aug 20, 2014 at 04:27:19PM +0200, Andreas Mohr wrote: 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? Right. There is also about a3d joystick not workign and I think a few others. 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. Fair enough. If you send me patches that fixes issues then I do not see any problem with it staying in. Vojtech also promised to dig out his old hardware. Thanks. -- Dmitry -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] SOUND: kill gameport bits
On Wed, Aug 20, 2014 at 02:15:30PM +0200, Takashi Iwai wrote: At Wed, 20 Aug 2014 09:05:58 +0200, Takashi Iwai wrote: Well, it worked on my test machine a year ago or so. Maybe I had a good luck. FYI, now I tested again an analog joystick on SB Live put on a Dell IvyBridge desktop with 3.17-rc1 x86-64 kernel, and it worked fine as is. So it's not that broken. That's probably because in your system TSCs are stable when switching CPU frequency. Earlier systems had bunch of issues there IIRC. Thanks. -- Dmitry -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] SOUND: kill gameport bits
On Tue, Aug 19, 2014 at 10:18:15PM -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)? Well, I did test some games with real joysticks e.g. in order to implement working Digital Enhanced Game Port support (where BTW the couple cards/driver combos which support that should also be completely unaffected by cpufreq since its delay accounting is digital). > > 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. Missed that one (not subscribed), sorry. > > 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. Yup, but at least not for the candidates above. > The bugs have been opened in bugzilla/reported on lists ages ago but nobody > stepped up to fix that. Ouch. I'm afraid I don't have any cpufreq-supporting hardware (hint, hint) which would enable me to work on it, though. > > 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. > They have better chance of being supported ;) I had a couple a few years back > and they did work for me. Good to know. I took a note to buy a good adapter as well. > > 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? Not me (I'm a developer). But other people probably would be inclined to do so, as long as sufficient support remains in place, on an architecture which is still in very wide use. And this case here (as opposed to e.g. the NI5010 ISA BNC network card where it was arguably very likely that it was totally unused) seems like a self-fulfilling prophecy... Andreas Mohr -- GNU/Linux. It's not the software that's free, it's you. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] SOUND: kill gameport bits
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)? > 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. > > 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. > 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? Thanks. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] SOUND: kill gameport bits
Reply-To: In-Reply-To: <1408466497-25640-1-git-send-email-dmitry.torok...@gmail.com> X-Priority: none 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) 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?). 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... 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 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... We already have an IMHO dangerous state in support of somewhat less mainstream hardware, so do we want to keep furthering that? Could we have more details/discussion prior to activities to remove whole subsystems? Thanks, Andreas Mohr -- GNU/Linux. It's not the software that's free, it's you. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] SOUND: kill gameport bits
Reply-To: In-Reply-To: 1408466497-25640-1-git-send-email-dmitry.torok...@gmail.com X-Priority: none 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) 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?). 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... 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 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... We already have an IMHO dangerous state in support of somewhat less mainstream hardware, so do we want to keep furthering that? Could we have more details/discussion prior to activities to remove whole subsystems? Thanks, Andreas Mohr -- GNU/Linux. It's not the software that's free, it's you. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] SOUND: kill gameport bits
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)? 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. 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. 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? Thanks. -- Dmitry -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] SOUND: kill gameport bits
On Tue, Aug 19, 2014 at 10:18:15PM -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)? Well, I did test some games with real joysticks e.g. in order to implement working Digital Enhanced Game Port support (where BTW the couple cards/driver combos which support that should also be completely unaffected by cpufreq since its delay accounting is digital). 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. Missed that one (not subscribed), sorry. 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. Yup, but at least not for the candidates above. The bugs have been opened in bugzilla/reported on lists ages ago but nobody stepped up to fix that. Ouch. I'm afraid I don't have any cpufreq-supporting hardware (hint, hint) which would enable me to work on it, though. 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. They have better chance of being supported ;) I had a couple a few years back and they did work for me. Good to know. I took a note to buy a good adapter as well. 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? Not me (I'm a developer). But other people probably would be inclined to do so, as long as sufficient support remains in place, on an architecture which is still in very wide use. And this case here (as opposed to e.g. the NI5010 ISA BNC network card where it was arguably very likely that it was totally unused) seems like a self-fulfilling prophecy... Andreas Mohr -- GNU/Linux. It's not the software that's free, it's you. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
