Re: [PATCH v2 0/4] Add ff-memless-next and make hid-lg4ff use it
On Mon, Feb 24, 2014 at 1:58 AM, Michal Malý madcatxs...@prifuk.cz wrote: On Monday 24 of February 2014 02:32:27 Anssi Hannula wrote: I think we should extend the current ff-memless instead of duplicating its functionality (even on a for now basis). Having looked at ff-memless-next briefly, it seems very similar to ff-memless on its basic working principle, and therefore I don't really see why extending ff-memless would be too cumbersome. Unless I'm missing something - in that case, feel free to point it out to me :) Deciding whether to patch ff-memless or write a new driver from scratch was a perfect example of being caught between the rock and a hard place. I am not particularly fond of the fact that we would have two modules doing pretty much the same thing. My reasons for writing a separate module were: - Periodic effects. ff-memless doesn't do real periodic effects, it simply emulates them through rumble effect. Devices without rumble effect support require emulation through constant force effect. Just this was not something one could write in one afternoon:) - Conditional effects. These effects cannot be by nature combined into one overall force (at least not easily) so they have to be handled one by one - this is a concept ff-memless does not seem to consider. FFB devices have limits as to how many conditional (referred to as uncombinable in MLNX) effects can be active simultaneously, etc. All in all it seemed less error prone to write a new driver based on the ff- memless logic, test and deploy it on devices I have access to and once we are sure there are no nasty regressions port the rest of the drivers to the new API. Given the scope of the changes I am afraid that a patch to ff-memless would be pretty close to a rewrite anyway. And add the fact that we already heavily tested the ff-memless-next driver. Unless you do a diff between the original ff-memless.c and the current ff-memless-next.c (which will result in a rather unintuitive patch), it would be a huge waste of time to retest the modified (when doing efforts to create an intuitive patch) ff-memless-next.c, considered my total time spend on testing (and not to speak of the time that Michal spent to fix the corresponding bugs.) I know that might not be much of an argument, but on the other side, my motivation to test again from scratch will be much lower (I can't change much on that, I'm afraid), which would eventually lead to lower reliability of the final product. Elias -- To unsubscribe from this list: send the line unsubscribe linux-input in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/4] Add ff-memless-next and make hid-lg4ff use it
On Mon, Feb 24, 2014 at 10:17:25PM +0100, Elias Vanderstuyft wrote: On Mon, Feb 24, 2014 at 1:58 AM, Michal Malý madcatxs...@prifuk.cz wrote: On Monday 24 of February 2014 02:32:27 Anssi Hannula wrote: I think we should extend the current ff-memless instead of duplicating its functionality (even on a for now basis). Having looked at ff-memless-next briefly, it seems very similar to ff-memless on its basic working principle, and therefore I don't really see why extending ff-memless would be too cumbersome. Unless I'm missing something - in that case, feel free to point it out to me :) Deciding whether to patch ff-memless or write a new driver from scratch was a perfect example of being caught between the rock and a hard place. I am not particularly fond of the fact that we would have two modules doing pretty much the same thing. My reasons for writing a separate module were: - Periodic effects. ff-memless doesn't do real periodic effects, it simply emulates them through rumble effect. Devices without rumble effect support require emulation through constant force effect. Just this was not something one could write in one afternoon:) - Conditional effects. These effects cannot be by nature combined into one overall force (at least not easily) so they have to be handled one by one - this is a concept ff-memless does not seem to consider. FFB devices have limits as to how many conditional (referred to as uncombinable in MLNX) effects can be active simultaneously, etc. All in all it seemed less error prone to write a new driver based on the ff- memless logic, test and deploy it on devices I have access to and once we are sure there are no nasty regressions port the rest of the drivers to the new API. Given the scope of the changes I am afraid that a patch to ff-memless would be pretty close to a rewrite anyway. And add the fact that we already heavily tested the ff-memless-next driver. Unless you do a diff between the original ff-memless.c and the current ff-memless-next.c (which will result in a rather unintuitive patch), it would be a huge waste of time to retest the modified (when doing efforts to create an intuitive patch) ff-memless-next.c, considered my total time spend on testing (and not to speak of the time that Michal spent to fix the corresponding bugs.) I know that might not be much of an argument, but on the other side, my motivation to test again from scratch will be much lower (I can't change much on that, I'm afraid), which would eventually lead to lower reliability of the final product. On the other hand having 2 drivers implementing very similar functionality would lead to general confusion as to which one should be used; they will also have to be maintained. I would rather see them merged into one driver providing necessary services to all memoryless FF devices. Thanks. -- Dmitry -- To unsubscribe from this list: send the line unsubscribe linux-input in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/4] Add ff-memless-next and make hid-lg4ff use it
On Monday 24 of February 2014 13:48:18 Dmitry Torokhov wrote: On Mon, Feb 24, 2014 at 10:17:25PM +0100, Elias Vanderstuyft wrote: On Mon, Feb 24, 2014 at 1:58 AM, Michal Malý madcatxs...@prifuk.cz wrote: On Monday 24 of February 2014 02:32:27 Anssi Hannula wrote: I think we should extend the current ff-memless instead of duplicating its functionality (even on a for now basis). Having looked at ff-memless-next briefly, it seems very similar to ff-memless on its basic working principle, and therefore I don't really see why extending ff-memless would be too cumbersome. Unless I'm missing something - in that case, feel free to point it out to me :) Deciding whether to patch ff-memless or write a new driver from scratch was a perfect example of being caught between the rock and a hard place. I am not particularly fond of the fact that we would have two modules doing pretty much the same thing. My reasons for writing a separate module were: - Periodic effects. ff-memless doesn't do real periodic effects, it simply emulates them through rumble effect. Devices without rumble effect support require emulation through constant force effect. Just this was not something one could write in one afternoon:) - Conditional effects. These effects cannot be by nature combined into one overall force (at least not easily) so they have to be handled one by one - this is a concept ff-memless does not seem to consider. FFB devices have limits as to how many conditional (referred to as uncombinable in MLNX) effects can be active simultaneously, etc. All in all it seemed less error prone to write a new driver based on the ff- memless logic, test and deploy it on devices I have access to and once we are sure there are no nasty regressions port the rest of the drivers to the new API. Given the scope of the changes I am afraid that a patch to ff-memless would be pretty close to a rewrite anyway. And add the fact that we already heavily tested the ff-memless-next driver. Unless you do a diff between the original ff-memless.c and the current ff-memless-next.c (which will result in a rather unintuitive patch), it would be a huge waste of time to retest the modified (when doing efforts to create an intuitive patch) ff-memless-next.c, considered my total time spend on testing (and not to speak of the time that Michal spent to fix the corresponding bugs.) I know that might not be much of an argument, but on the other side, my motivation to test again from scratch will be much lower (I can't change much on that, I'm afraid), which would eventually lead to lower reliability of the final product. On the other hand having 2 drivers implementing very similar functionality would lead to general confusion as to which one should be used; they will also have to be maintained. I would rather see them merged into one driver providing necessary services to all memoryless FF devices. Thanks. Very well. It that case I guess the most sensible thing to do would be to add FF_RUMBLE to ff-memless-next and replace ff-memless completely. As Anssi pointed out a lot of the drivers that currently use ff-memless are very simple so any risk of breakage will hopefully be minimal. As I don't have any device with rumble effect support I'll appreciate help on this front Michal M. -- To unsubscribe from this list: send the line unsubscribe linux-input in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/4] Add ff-memless-next and make hid-lg4ff use it
Hi everybody, this patch series is a result of my work to improve FFB support for memoryless devices. ff-memless-next is an improvement over the currently available ff-memless which is well suited for joypads but cannot handle more advanced devices such as racing wheels properly. As I have explained in one of RFCs regarding ff-memless-next, the extent of the changes makes implementing ff-memless-next as a patch to ff-memless unfeasible. As of now there is a total of 27 drivers using ff-memless (including lg4ff) - a lot of them joypads. I do not have access to any FFB joypad at the moment so I cannot implement the functionality required to handle joypads properly - namely FF_RUMBLE and emulation of FF_PERIODIC through FF_RUMBLE. The plan is to implement the missing functionality and replace ff-memless completely in the future. Second part of this series ports lg4ff driver over to ff-memless-next. The immediate benefit of this is support of all periodic effects and ramp effect. v2 addresses a few issues that have not been noticed at the time v1 was submitted. Specific fixes are mentioned in the respective patches. Michal M. Michal Malý (4): INPUT: Add ff-memless-next module HID: Port hid-lg4ff to ff-memless-next HID: Add support for periodic effects in hid-lg4ff HID: Add support for ramp effect in hid-lg4ff Documentation/input/ff-memless-next.txt | 141 ++ drivers/hid/Kconfig | 2 +- drivers/hid/hid-lg4ff.c | 93 ++-- drivers/input/Kconfig | 11 + drivers/input/Makefile | 1 + drivers/input/ff-memless-next.c | 789 include/linux/input/ff-memless-next.h | 32 ++ 7 files changed, 1033 insertions(+), 36 deletions(-) -- 1.9.0 -- -- To unsubscribe from this list: send the line unsubscribe linux-input in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/4] Add ff-memless-next and make hid-lg4ff use it
24.02.2014 01:24, Michal Malý kirjoitti: Hi everybody, Hi, this patch series is a result of my work to improve FFB support for memoryless devices. ff-memless-next is an improvement over the currently available ff-memless which is well suited for joypads but cannot handle more advanced devices such as racing wheels properly. As I have explained in one of RFCs regarding ff-memless-next, the extent of the changes makes implementing ff-memless-next as a patch to ff-memless unfeasible. As of now there is a total of 27 drivers using ff-memless (including lg4ff) - a lot of them joypads. I do not have access to any FFB joypad at the moment so I cannot implement the functionality required to handle joypads properly - namely FF_RUMBLE and emulation of FF_PERIODIC through FF_RUMBLE. The plan is to implement the missing functionality and replace ff-memless completely in the future. I think we should extend the current ff-memless instead of duplicating its functionality (even on a for now basis). Having looked at ff-memless-next briefly, it seems very similar to ff-memless on its basic working principle, and therefore I don't really see why extending ff-memless would be too cumbersome. Unless I'm missing something - in that case, feel free to point it out to me :) Duplicating the module makes reviewing it somewhat difficult since the changes are not clearly visible. As for the amount of drivers using ff-memless, those are ~all very simple (single function call registering a single callback) so it should be easy to apply any API conversion if needed. And I don't see a real need for you to have access to a rumble joypad - that support is already implemented in ff-memless, and other people can test that it isn't broken by your changes. Regardless, thanks for looking into this. Second part of this series ports lg4ff driver over to ff-memless-next. The immediate benefit of this is support of all periodic effects and ramp effect. v2 addresses a few issues that have not been noticed at the time v1 was submitted. Specific fixes are mentioned in the respective patches. Michal M. Michal Malý (4): INPUT: Add ff-memless-next module HID: Port hid-lg4ff to ff-memless-next HID: Add support for periodic effects in hid-lg4ff HID: Add support for ramp effect in hid-lg4ff Documentation/input/ff-memless-next.txt | 141 ++ drivers/hid/Kconfig | 2 +- drivers/hid/hid-lg4ff.c | 93 ++-- drivers/input/Kconfig | 11 + drivers/input/Makefile | 1 + drivers/input/ff-memless-next.c | 789 include/linux/input/ff-memless-next.h | 32 ++ 7 files changed, 1033 insertions(+), 36 deletions(-) -- 1.9.0 -- -- Anssi Hannula -- To unsubscribe from this list: send the line unsubscribe linux-input in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/4] Add ff-memless-next and make hid-lg4ff use it
On Monday 24 of February 2014 02:32:27 Anssi Hannula wrote: 24.02.2014 01:24, Michal Malý kirjoitti: Hi everybody, Hi, this patch series is a result of my work to improve FFB support for memoryless devices. ff-memless-next is an improvement over the currently available ff-memless which is well suited for joypads but cannot handle more advanced devices such as racing wheels properly. As I have explained in one of RFCs regarding ff-memless-next, the extent of the changes makes implementing ff-memless-next as a patch to ff-memless unfeasible. As of now there is a total of 27 drivers using ff-memless (including lg4ff) - a lot of them joypads. I do not have access to any FFB joypad at the moment so I cannot implement the functionality required to handle joypads properly - namely FF_RUMBLE and emulation of FF_PERIODIC through FF_RUMBLE. The plan is to implement the missing functionality and replace ff-memless completely in the future. I think we should extend the current ff-memless instead of duplicating its functionality (even on a for now basis). Having looked at ff-memless-next briefly, it seems very similar to ff-memless on its basic working principle, and therefore I don't really see why extending ff-memless would be too cumbersome. Unless I'm missing something - in that case, feel free to point it out to me :) Deciding whether to patch ff-memless or write a new driver from scratch was a perfect example of being caught between the rock and a hard place. I am not particularly fond of the fact that we would have two modules doing pretty much the same thing. My reasons for writing a separate module were: - Periodic effects. ff-memless doesn't do real periodic effects, it simply emulates them through rumble effect. Devices without rumble effect support require emulation through constant force effect. Just this was not something one could write in one afternoon:) - Conditional effects. These effects cannot be by nature combined into one overall force (at least not easily) so they have to be handled one by one - this is a concept ff-memless does not seem to consider. FFB devices have limits as to how many conditional (referred to as uncombinable in MLNX) effects can be active simultaneously, etc. All in all it seemed less error prone to write a new driver based on the ff- memless logic, test and deploy it on devices I have access to and once we are sure there are no nasty regressions port the rest of the drivers to the new API. Given the scope of the changes I am afraid that a patch to ff-memless would be pretty close to a rewrite anyway. Duplicating the module makes reviewing it somewhat difficult since the changes are not clearly visible. As for the amount of drivers using ff-memless, those are ~all very simple (single function call registering a single callback) so it should be easy to apply any API conversion if needed. And I don't see a real need for you to have access to a rumble joypad - that support is already implemented in ff-memless, and other people can test that it isn't broken by your changes. It has been my intention to add handling of rumble effects in a followup patch. I wanted to limit the extent of changes I dump in a one massive patch, especially when I cannot test the rumble effect on a real hardware. Michal -- To unsubscribe from this list: send the line unsubscribe linux-input in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
