From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To: Tim Schumacher <timschumi@gmx.de>
Cc: linux-input@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 01/20] Input: iforce - remove "being used" silliness
Date: Tue, 18 Jun 2019 17:24:48 -0700 [thread overview]
Message-ID: <20190619002448.GC62571@dtor-ws> (raw)
In-Reply-To: <3505434a-f5ec-de50-5f94-7347c6926f40@gmx.de>
On Wed, Jun 12, 2019 at 04:44:00PM +0200, Tim Schumacher wrote:
> On 19.09.18 19:10, Dmitry Torokhov wrote:
> > On Wed, Sep 19, 2018 at 04:51:26PM +0200, Tim Schumacher wrote:
> >> On 18.09.18 02:47, Dmitry Torokhov wrote:
> >>> The kernel is supposed to handle multiple devices, static flags
> >>> in packet handling code will never work.
> >>>
> >>> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> >>> ---
> >>>
> >>> This is a random assortment of iforce patches that I made a few weeks back.
> >>>
> >>> Tim, I do not have hardware, so I was bound to screw it up, but if you
> >>> have some time I'd appreciate if you try them out (and if I indeed broke
> >>> things if you could identify issues that would be even more awesome).
> >>>
> >>> Thanks!
> >>>
> >> Hello Dmitry,
> >>
> >> I tested those patches and I didn't find any obvious issues. The basic functions
> >> do work (i.e. buttons and axes, don't have a HAT so I can't test that), force
> >> feedback seems to work to the extent it was before (I only have fftest though,
> >> no games that support force feedback). I'll go through a few more applications
> >> and see if anything not obvious is broken.
> >>
> >
> > Thank you for taking a look.
> >
> >> Unfortunately, I only have that one wheel and I can only test USB connections
> >> at the moment (unless I find a proper serial adaptor, but I'm not sure if that
> >> would even work).
> >>
> >> Are those patches planned to go into 4.19 or are they intended to be merged in
> >> the next development cycle?
> >
> > Definitely not 4.19. Could be 4.20 or 4.21...
> >
> > Thanks.
> >
>
> Hello Dmitry,
>
> as a followup to the last E-Mail I sent about this topic, the complete chain
> of patches has been in my personal tree since September of 2018 and there
> have been no issues so far as well. I tested a few more games and utilities,
> and I was able to test with multiple wheels simultaneously as well.
>
> In the end it's still your decision, but imo those patches should be fine
Thank you Tim, I'll put your name down as Tested-by then.
--
Dmitry
prev parent reply other threads:[~2019-06-19 0:24 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-18 0:47 [PATCH 01/20] Input: iforce - remove "being used" silliness Dmitry Torokhov
2018-09-18 0:47 ` [PATCH 02/20] Input: iforce - introduce transport ops Dmitry Torokhov
2018-09-18 0:47 ` [PATCH 03/20] Input: iforce - move get_id to the transport operations Dmitry Torokhov
2018-09-18 0:47 ` [PATCH 04/20] Input: iforce - move command completion handling to serio code Dmitry Torokhov
2018-09-18 0:47 ` [PATCH 05/20] Input: iforce - introduce start and stop io transport ops Dmitry Torokhov
2018-09-18 0:47 ` [PATCH 06/20] Input: iforce - add bus type and parent arguments to iforce_init_device() Dmitry Torokhov
2018-09-18 0:47 ` [PATCH 07/20] Input: iforce - move transport data into transport modules Dmitry Torokhov
2018-09-18 0:47 ` [PATCH 08/20] Input: iforce - split into core and " Dmitry Torokhov
2018-09-18 0:47 ` [PATCH 09/20] Input: iforce - use DMA-safe buffer when getting IDs from USB Dmitry Torokhov
2018-09-18 0:47 ` [PATCH 10/20] Input: iforce - update formatting of switch statements Dmitry Torokhov
2018-09-18 0:47 ` [PATCH 11/20] Input: iforce - factor out hat handling when parsing packets Dmitry Torokhov
2018-09-18 0:47 ` [PATCH 12/20] Input: iforce - do not combine arguments for iforce_process_packet() Dmitry Torokhov
2018-09-18 0:47 ` [PATCH 13/20] Input: iforce - signal command completion from transport code Dmitry Torokhov
2018-09-18 0:47 ` [PATCH 14/20] Input: iforce - only call iforce_process_packet() if initialized Dmitry Torokhov
2018-09-18 0:47 ` [PATCH 15/20] Input: iforce - allow callers supply data buffer when fetching device IDs Dmitry Torokhov
2018-09-18 0:47 ` [PATCH 16/20] Input: iforce - use DMA-safe buffores for USB transfers Dmitry Torokhov
2018-09-18 0:47 ` [PATCH 17/20] Input: only credit entropy when events are generated by a device Dmitry Torokhov
2018-09-18 0:47 ` [PATCH 18/20] Input: iforce - drop bus type from iforce structure Dmitry Torokhov
2018-09-18 0:47 ` [PATCH 19/20] Input: iforce - drop couple of temps from transport code Dmitry Torokhov
2018-09-18 0:47 ` [PATCH 20/20] Input: iforce - use unaligned accessors, where appropriate Dmitry Torokhov
2018-09-19 14:51 ` [PATCH 01/20] Input: iforce - remove "being used" silliness Tim Schumacher
2018-09-19 17:10 ` Dmitry Torokhov
2019-06-12 14:44 ` Tim Schumacher
2019-06-19 0:24 ` Dmitry Torokhov [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190619002448.GC62571@dtor-ws \
--to=dmitry.torokhov@gmail.com \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=timschumi@gmx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.