Hi! I have checked http://projects.goldelico.com/p/gta04-kernel/issues/ , but I find the descriptions too brief for a newcomer to understand. They are good as a memorisation notes for who have written them, though :)
So I'd like to ask for 2-3 issues which are still actual and important (to avoid looking at outdated tickets), but which are not on a priority list of other developers, so that I don't hijack somebody's task. I don't know yet which amount of spoon-feeding I would need - I hope very little of it - but still if it's something about any chips, I'd need access to datasheets; if it's about mainlining, then I'd need a context - whether it was pushed before, which were rejection reasons, etc.
Actually I think mainlining tasks would require less of load on you, as I'm not proficient on hardware, but experienced on LKML review process.
Hi Andrey,
Am 28.05.2016 um 00:50 schrieb Andrey Utkin andrey_utkin@fastmail.com:
Hi! I have checked http://projects.goldelico.com/p/gta04-kernel/issues/ , but I find the descriptions too brief for a newcomer to understand. They are good as a memorisation notes for who have written them, though :)
Well, that is the main purpose of the issue tracker so far :)
So let's improve on that...
In total there are only ~10-12 of them relevant for the Pyra. Several others are for the GTA04 hardware. BTW, we will have a kernel hacking workshop next weekend in Munich to address some of them.
So I'd like to ask for 2-3 issues which are still actual and important (to avoid looking at outdated tickets), but which are not on a priority list of other developers, so that I don't hijack somebody's task. I don't know yet which amount of spoon-feeding I would need - I hope very little of it - but still if it's something about any chips, I'd need access to datasheets;
Yes, I am preparing a download server where also NDA covered data sheets can be made available to trusted participants.
if it's about mainlining, then I'd need a context
- whether it was pushed before, which were rejection reasons, etc.
You can find some of these discussions in the letux-kernel archive (started in February):
http://lists.goldelico.com/pipermail/letux-kernel/2016-April/thread.html
Rejection reasons are sometimes difficult to grasp. For example for our bluetooth power-automatic driver (called uart-slaves) the official MAINTAINERS didn't comment. Except Alan Cox (hidden behind a synonym) and complained how difficult it is to change anything in the tty stack, turning around any word I wrote, and finally "plonking" me. So there was no fruitful discussion at all... Sometimes people complained and asked to shut up, instead of giving technical reasons or answering a request for a requirements or style-guide document. So the rejection reason might be that I pointed out lack of concept on maintainers side but they could only say that my proposal doesn't fit into their vague concepts. But they were not able to describe it to me in textbook quality.
Actually I think mainlining tasks would require less of load on you, as I'm not proficient on hardware, but experienced on LKML review process.
Well, the key problem of the LKML review process is that you have something working and well thought - but one of the thoughts is not accepted or understood by maintainers. This means turning the code upside down and expand what had been clean :)
This may take much more time than anticipated and needs to stay focussed on collecting feedbacks. And working them in. So it might be 30% of total efforts to get something working and 70% to get it accepted.
Anyways that is something we have to go through.
The last driver I submitted to LMKL is the is31fl319x driver. I already got a lot of feedback and prepared a V2:
http://git.goldelico.com/?p=gta04-kernel.git;a=shortlog;h=refs/heads/work/hn...
But one significant change hasn't been worked in (because ours works equally well). They suggested to use some very new features of the gpiolib to get rid of locking in the driver. I generally would prefer that as well but testing locking (and debugging if it does not work) is extremely time consuming (and needs hardware to test on).
So generally I think this is probably not the right phase to jump in and take over.
Perhaps after I fixed what I already got as feedback and submitted again. Then, you can already participate in the discussion and it might be much easier to understand the LKML feedbacks than if I try to summarise...
But there are also work packages for new drivers where nobody did take care so far. We have these sensor chips: * BMC160 * BMG150 * or BNO055 * BME280
For some we don't have any or good enough (iio) drivers. Bosch Sensortec has some libraries. And there are drivers for similar chips. So that could be a topic where you can start from scratch and proceed in your own pace. And they are not too complex to start with.
Another (almost) unprocessed task is the eMMC/µSD-Switch which IMHO should get a driver that can switch between both on demand. My work so far is just a bindings document to describe how *I* think it could be integrated into the DT. This is
issue http://projects.goldelico.com/p/gta04-kernel/issues/698/ and branch http://git.goldelico.com/?p=gta04-kernel.git;a=shortlog;h=refs/heads/work/hn...
Generally it is a little difficult to advise which issues to address next/best. More will come up as more hardware is built and distributed.
Hopefully I have not written too much and made it look more complex than it is :) Please ask.
Best regards, Nikolaus
On Sat, May 28, 2016 at 01:30:56PM +0200, H. Nikolaus Schaller wrote:
Well, the key problem of the LKML review process is that you have something working and well thought - but one of the thoughts is not accepted or understood by maintainers. This means turning the code upside down and expand what had been clean :)
Well, LKML review requires huge amount of stubbornness (just as all driver work :) ). I know it because I'm now mainlining tw5864 driver for another job :)
In my experience maintainers are saint guys because they make most of work on evolution of API (and collateral changes across all drivers), which makes drivers more and more slim.
But there are also work packages for new drivers where nobody did take care so far. We have these sensor chips:
- BMC160
- BMG150
- or BNO055
- BME280
For some we don't have any or good enough (iio) drivers. Bosch Sensortec has some libraries. And there are drivers for similar chips. So that could be a topic where you can start from scratch and proceed in your own pace. And they are not too complex to start with.
All of them at board, or some are substitusions for others? Please explain the "or" part. Please point me to all the datasheets once they become available for download.
Are these chips available on any devboards anybody is having?
BTW what about some ready solution for sharing NDA files privately, for example, private Bitbucket git repo? It's free to set up and you can share access to persons you want.
Another (almost) unprocessed task is the eMMC/µSD-Switch which IMHO should get a driver that can switch between both on demand. My work so far is just a bindings document to describe how *I* think it could be integrated into the DT. This is
issue http://projects.goldelico.com/p/gta04-kernel/issues/698/ and branch http://git.goldelico.com/?p=gta04-kernel.git;a=shortlog;h=refs/heads/work/hn...
Hm. Does it mean that eMMC and mSD cannot be accessed at the same time? (Which feel sad). I'm not keen on devicetree stuff, but just a dumb proposal - what about defining both, and then let the requests to blocked device (which is unavailable at the moment) return EIO or EAGAIN. If there's such thing as handler procedure, of course :)
Hi Andrey,
Am 28.05.2016 um 15:14 schrieb Andrey Utkin andrey_utkin@fastmail.com:
On Sat, May 28, 2016 at 01:30:56PM +0200, H. Nikolaus Schaller wrote:
Well, the key problem of the LKML review process is that you have something working and well thought - but one of the thoughts is not accepted or understood by maintainers. This means turning the code upside down and expand what had been clean :)
Well, LKML review requires huge amount of stubbornness
indeed. I just didn't find the right single word :)
Usually I can be quite stubborn on demand, but not for multiple topics in parallel... Then I have to prioritize and one or the other isn't pushed as it were necessary.
(just as all driver work :) ). I know it because I'm now mainlining tw5864 driver for another job :)
interesting chip!
In my experience maintainers are saint guys because they make most of work on evolution of API (and collateral changes across all drivers), which makes drivers more and more slim.
Yes, this is something to be appreciated... It would just be easier if it were better documented/communicated.
But there are also work packages for new drivers where nobody did take care so far. We have these sensor chips:
- BMC160
- BMG150
- or BNO055
- BME280
For some we don't have any or good enough (iio) drivers. Bosch Sensortec has some libraries. And there are drivers for similar chips. So that could be a topic where you can start from scratch and proceed in your own pace. And they are not too complex to start with.
All of them at board, or some are substitusions for others? Please explain the "or" part.
The "or" means that it is not 100% finally decided if there will be BMC160+BMG150 or BNO055 and they have overlapping functionality.
Please point me to all the datasheets once they become available for download.
I think for the sensors they are even public:
https://ae-bst.resource.bosch.com/media/_tech/media/datasheets/BST-BMC150-DS... https://ae-bst.resource.bosch.com/media/_tech/media/datasheets/BST-BMG160-DS... https://ae-bst.resource.bosch.com/media/_tech/media/datasheets/BST-BME280_DS... https://ae-bst.resource.bosch.com/media/_tech/media/datasheets/BST_BNO055_DS...
There is a user-space driver for the BNO055 but some iio kernel driver would be better: https://github.com/BoschSensortec/BNO055_driver
Are these chips available on any devboards anybody is having?
Yes, the prototypes have them (I am not sure about the BNO055 but it can even be retrofitted and AFAIR there is no I2C address conflict).
BTW what about some ready solution for sharing NDA files privately, for example, private Bitbucket git repo? It's free to set up and you can share access to persons you want.
Yes, it is a similar solution almost set up. I even have chosen and prepared the relevant data sheets. They are just not copied to the right location on my server (and access permissions set up).
Another (almost) unprocessed task is the eMMC/µSD-Switch which IMHO should get a driver that can switch between both on demand. My work so far is just a bindings document to describe how *I* think it could be integrated into the DT. This is
issue http://projects.goldelico.com/p/gta04-kernel/issues/698/ and branch http://git.goldelico.com/?p=gta04-kernel.git;a=shortlog;h=refs/heads/work/hn...
Hm. Does it mean that eMMC and mSD cannot be accessed at the same time? (Which feel sad).
Well, it is a limitation of the OMAP5432 that it has just 4 MMC/SDIO ports and we need 5 (the OMAP5430 would have had a 5th one)...
We want: 2 big SD slots 1 WLAN SDIO 1 eMMC 1 µSD
So we added an SDIO multiplexer which allows to use one interface for alternatively access eMMC and µSD. There is also a hardware switch logic so that pressing a shoulder button chooses which one will be used for the first and second stage boot loader. This is turned off by U-Boot so that the switch is under 100% software control in Linux.
For Linux it would be nice if user space simply would 5 independent interfaces.
I'm not keen on devicetree stuff, but just a dumb proposal - what about defining both, and then let the requests to blocked device (which is unavailable at the moment) return EIO or EAGAIN. If there's such thing as handler procedure, of course :)
Yes, would probably be a simple, manually operated solution for a start. We could provide a private /sys node by the switch driver to throw the switch in either direction (echo emmc >/sys/something).
In the long run I think the driver should correctly queue up requests and allow to mix them by throwing the switch on demand. This will of course share the bandwidth of the mmc interface.
What we need in any case is to properly tell the kernel that there is a switch sitting on one specific omap hsmmc interface and that it provides two additional mmc ports. That is what I hope the DT idea would allow to configure the driver. So that the driver can register two new mmc ports (by mmc_add_host() ?) and it must itself register as some mmc client (similar to the WLAN drivers).
BR, Nikolaus
On Sun, May 29, 2016 at 07:33:07AM +0200, H. Nikolaus Schaller wrote:
I think for the sensors they are even public:
https://ae-bst.resource.bosch.com/media/_tech/media/datasheets/BST-BMC150-DS... https://ae-bst.resource.bosch.com/media/_tech/media/datasheets/BST-BMG160-DS... https://ae-bst.resource.bosch.com/media/_tech/media/datasheets/BST-BME280_DS... https://ae-bst.resource.bosch.com/media/_tech/media/datasheets/BST_BNO055_DS...
There is a user-space driver for the BNO055 but some iio kernel driver would be better: https://github.com/BoschSensortec/BNO055_driver
Thanks for links. Really nice datasheets.
BTW There is a ready kernal driver for BMG160: https://github.com/BoschSensortec/Linux_Kernel_Drivers/tree/master/drivers/i...
Would it be fine to just forward-port this driver, or something must be changed in interfaces?
Making drivers for the chips listed above seems a good task for me, I will work on this.
I see the Sensortec drivers use I2C. Is it a way to go for Pyra board? I.e. not SPI (which is also an option for those chips)?
Just in case - do we have any contact with customer support people from BOSCH besides email contact@bosch-sensortec.com ?
Hi,
Am 29.05.2016 um 13:27 schrieb Andrey Utkin andrey_utkin@fastmail.com:
On Sun, May 29, 2016 at 07:33:07AM +0200, H. Nikolaus Schaller wrote:
I think for the sensors they are even public:
https://ae-bst.resource.bosch.com/media/_tech/media/datasheets/BST-BMC150-DS... https://ae-bst.resource.bosch.com/media/_tech/media/datasheets/BST-BMG160-DS... https://ae-bst.resource.bosch.com/media/_tech/media/datasheets/BST-BME280_DS... https://ae-bst.resource.bosch.com/media/_tech/media/datasheets/BST_BNO055_DS...
There is a user-space driver for the BNO055 but some iio kernel driver would be better: https://github.com/BoschSensortec/BNO055_driver
Thanks for links. Really nice datasheets.
You are welcome :)
BTW There is a ready kernal driver for BMG160: https://github.com/BoschSensortec/Linux_Kernel_Drivers/tree/master/drivers/i...
Ah, yes.
Would it be fine to just forward-port this driver, or something must be changed in interfaces?
I think it just needs to be tested/configured in DT if it does not work. So this is a work package with real hardware in your hands...
Making drivers for the chips listed above seems a good task for me, I will work on this.
Great!
BTW: the BME280 has two sensors in one and the BMP085 should be very similar. AFAIR the BMC150 also has two chips inside (BMM150 and some BMA220). For the latter there is also a driver.
I see the Sensortec drivers use I2C. Is it a way to go for Pyra board?
Yes.
I.e. not SPI (which is also an option for those chips)?
No. Would have needed 4 wires to go around the board - and we do not need very high speed (polling frequency i s usually <10Hz).
Just in case - do we have any contact with customer support people from BOSCH besides email contact@bosch-sensortec.com ?
Yes, I have a contact to the designer of the BNO055 chip but would have to ask first if he can support someone else.
BR, Nikolaus
On Sun, May 29, 2016 at 01:32:34PM +0200, H. Nikolaus Schaller wrote:
BTW There is a ready kernal driver for BMG160: https://github.com/BoschSensortec/Linux_Kernel_Drivers/tree/master/drivers/i...
Ah, yes.
I am somewhat confused by what you've written earlier:
We have these sensor chips:
- BMC160
- BMG150
- or BNO055
- BME280
But now I see that there's no datasheet available for BMG150 and BMC160 - only BMG160 and BMC150.
BUT, there's drivers/iio/{magnetometer,accel}/bmc150* in upstream kernel.
But for BMG, there's just drivers/iio/gyro/bmg160* , so no "150".
Could you please confirm exact chip names?
BTW: the BME280 has two sensors in one and the BMP085 should be very similar. AFAIR the BMC150 also has two chips inside (BMM150 and some BMA220). For the latter there is also a driver.
BME280 support has been developed lately by one guy from Intel (BTW seems all Bosch drivers in mainline kernel are maintained by Intel), it is pending some likely-trivial rebasing and resubmission to kernel upstream: http://www.spinics.net/lists/linux-iio/msg23988.html
I could contact him to ask about his plans for new submission, and if there's any more code we could benefit from :)
BTW Intel has some IoT project which includes drivers for many of mentioned chips, but not in form of Linux kernel modules: https://github.com/intel-iot-devkit/upm/pull/423
So, if we pretend that we've got BME280 driver, and those bm[cg]1[56]0 which are already in upstream kernel, which drivers are still lacking?
Hi Andrey,
Am 07.06.2016 um 00:51 schrieb Andrey Utkin andrey_utkin@fastmail.com:
On Sun, May 29, 2016 at 01:32:34PM +0200, H. Nikolaus Schaller wrote:
BTW There is a ready kernal driver for BMG160: https://github.com/BoschSensortec/Linux_Kernel_Drivers/tree/master/drivers/i...
Ah, yes.
I am somewhat confused by what you've written earlier:
We have these sensor chips:
- BMC160
- BMG150
- or BNO055
- BME280
But now I see that there's no datasheet available for BMG150 and BMC160
- only BMG160 and BMC150.
BUT, there's drivers/iio/{magnetometer,accel}/bmc150* in upstream kernel.
But for BMG, there's just drivers/iio/gyro/bmg160* , so no "150".
Could you please confirm exact chip names?
Sorry for the confusion. Was my fault. I mixed them up in my original mail. We have indeed BMC150 and BMG160.
BTW: the BME280 has two sensors in one and the BMP085 should be very similar. AFAIR the BMC150 also has two chips inside (BMM150 and some BMA220). For the latter there is also a driver.
BME280 support has been developed lately by one guy from Intel (BTW seems all Bosch drivers in mainline kernel are maintained by Intel), it is pending some likely-trivial rebasing and resubmission to kernel upstream: http://www.spinics.net/lists/linux-iio/msg23988.html
Oh that is a very interesting finding! Thank you.
I could contact him to ask about his plans for new submission, and if there's any more code we could benefit from :)
Yes, please. Any piece of information we can get could help. And any push to get it into mainline helps as well.
So we simply should wait for the submission to LKML. Then I can include it in our "forward ports" branch so that we have it - until it trickles into linus/master. Then we can remove it as our private addition.
One thing we still have to add/fix will be the DT node. Maybe you could look into the bindings defined by the Intel guy and check what we have to change (if anything). Current Pyra DT is:
http://git.goldelico.com/?p=gta04-kernel.git;a=blob;f=arch/arm/boot/dts/pyra...
It looks quite preliminary/partially wrong to me (even if I have written it :).
Hope to fix the boards this week so that you can get hardware to test on asap.
BTW Intel has some IoT project which includes drivers for many of mentioned chips, but not in form of Linux kernel modules: https://github.com/intel-iot-devkit/upm/pull/423
Well, IoT is usually done with small microcontrollers and rarely with Linux...
So, if we pretend that we've got BME280 driver, and those bm[cg]1[56]0 which are already in upstream kernel, which drivers are still lacking?
So your findings show that it is less lacking than I had thought. So we will soon have drivers for the standard sensor set.
There is the BNO055 which ED has not choosen for cost reasons. But I am working with my contact with Bosch and he tries to get special conditions. Looks like they want to support us and use Pyra as a reference design :) He is also looking for a technical contact.
Thanks and BR, Nikolaus
On Tue, Jun 07, 2016 at 08:03:41AM +0200, H. Nikolaus Schaller wrote:
There is the BNO055 which ED has not choosen for cost reasons. But I am working with my contact with Bosch and he tries to get special conditions. Looks like they want to support us and use Pyra as a reference design :) He is also looking for a technical contact.
So Vlad Dogaru from Intel replied that he likely has put work on BNO055 to his schedule.
What about me, what else useful I could do?
What if I pick some stabilized drivers or patches which are not yet mainlined and push them to mainline?
Hi Andrey,
Am 11.06.2016 um 01:25 schrieb Andrey Utkin andrey_utkin@fastmail.com:
On Tue, Jun 07, 2016 at 08:03:41AM +0200, H. Nikolaus Schaller wrote:
There is the BNO055 which ED has not choosen for cost reasons. But I am working with my contact with Bosch and he tries to get special conditions. Looks like they want to support us and use Pyra as a reference design :) He is also looking for a technical contact.
So Vlad Dogaru from Intel replied that he likely has put work on BNO055 to his schedule.
Thanks that you did request this from him!
What about me, what else useful I could do?
What if I pick some stabilized drivers or patches which are not yet mainlined and push them to mainline?
I have looked through those branches/features we have not yet tried to upstream. Those we already have tried needs some interaction with the original developer(s) so that there is no duplicate work. And some are just missing small cleanup before upstreaming which is easier to apply than to explain someone else.
I only came up with the nub/joystick driver which works, but has not yet been pushed at all:
http://git.goldelico.com/?p=gta04-kernel.git;a=shortlog;h=refs/heads/work/hn...
All others are either not mature enough for upstreaming or in some intermediate LKML review stage (in most cases there has been feedback but is not worked completely into version n+1 so it is difficult to define/describe the current status - except that it works for us).
One important driver is still empty and needs real driver development work:
http://git.goldelico.com/?p=gta04-kernel.git;a=shortlog;h=refs/heads/work/hn...
So I would say you could try to clean up the as5013 driver first and then try to get it upstream. A minor problem is that you can't easily test the cleaned up version and if feedback asks to solve something differently.
Or you start to work out a draft for the txs02612 driver.
After we have distributed hardware, it is easier to collaboratively work on the other parts (since you can test and we can discuss fixes).
BR, Nikolaus
On Mon, Jun 13, 2016 at 02:11:53PM +0200, H. Nikolaus Schaller wrote:
I only came up with the nub/joystick driver which works, but has not yet been pushed at all:
http://git.goldelico.com/?p=gta04-kernel.git;a=shortlog;h=refs/heads/work/hn...
This looks like a good task for me. Thanks.
So I would say you could try to clean up the as5013 driver first and then try to get it upstream. A minor problem is that you can't easily test the cleaned up version and if feedback asks to solve something differently.
Looks like original authorship of Grazvydas Ignotas should be left, despite numerous changes by you (and apparently future cleanup by me). Right? Other contributors could be mentioned in the commit message.
All others are either not mature enough for upstreaming or in some intermediate LKML review stage (in most cases there has been feedback but is not worked completely into version n+1 so it is difficult to define/describe the current status - except that it works for us).
I'm fine to dig feedback from history and to make some n+1's, when I'm done with nub driver.
One important driver is still empty and needs real driver development work:
http://git.goldelico.com/?p=gta04-kernel.git;a=shortlog;h=refs/heads/work/hn...
Looked interesting until I reviewed the datasheet PDF (of 25 pages), then I've realized that I have no idea what to do with this :) Everything is about electricity, no "registers i/o" to which I'm accustomed :)
Am Mon, 13 Jun 2016 16:15:37 +0300 hat Andrey Utkin andrey_utkin@fastmail.com geschrieben:
Hi,
one more information about the nub/joystick driver.
While it DOES work, it's a bit of a hack and can be done in a better way. notaz (Grazvydas) suggested to change that driver so that the nubs report themselves as Input devices for X, so they can be more flexible and properly configured with the X Server.
On Mon, Jun 13, 2016 at 02:11:53PM +0200, H. Nikolaus Schaller wrote:
I only came up with the nub/joystick driver which works, but has not yet been pushed at all:
http://git.goldelico.com/?p=gta04-kernel.git;a=shortlog;h=refs/heads/work/hn...
This looks like a good task for me. Thanks.
So I would say you could try to clean up the as5013 driver first and then try to get it upstream. A minor problem is that you can't easily test the cleaned up version and if feedback asks to solve something differently.
Looks like original authorship of Grazvydas Ignotas should be left, despite numerous changes by you (and apparently future cleanup by me). Right? Other contributors could be mentioned in the commit message.
All others are either not mature enough for upstreaming or in some intermediate LKML review stage (in most cases there has been feedback but is not worked completely into version n+1 so it is difficult to define/describe the current status - except that it works for us).
I'm fine to dig feedback from history and to make some n+1's, when I'm done with nub driver.
One important driver is still empty and needs real driver development work:
http://git.goldelico.com/?p=gta04-kernel.git;a=shortlog;h=refs/heads/work/hn...
Looked interesting until I reviewed the datasheet PDF (of 25 pages), then I've realized that I have no idea what to do with this :) Everything is about electricity, no "registers i/o" to which I'm accustomed :)
Am 13.06.2016 um 15:32 schrieb Michael Mrozek EvilDragon@openpandora.org:
Am Mon, 13 Jun 2016 16:15:37 +0300 hat Andrey Utkin andrey_utkin@fastmail.com geschrieben:
Hi,
one more information about the nub/joystick driver.
While it DOES work, it's a bit of a hack and can be done in a better way. notaz (Grazvydas) suggested to change that driver so that the nubs report themselves as Input devices for X, so they can be more flexible and properly configured with the X Server.
They do present themselves as /dev/input/event* which is what X Server is looking for.
On Mon, Jun 13, 2016 at 02:11:53PM +0200, H. Nikolaus Schaller wrote:
I only came up with the nub/joystick driver which works, but has not yet been pushed at all:
http://git.goldelico.com/?p=gta04-kernel.git;a=shortlog;h=refs/heads/work/hn...
This looks like a good task for me. Thanks.
So I would say you could try to clean up the as5013 driver first and then try to get it upstream. A minor problem is that you can't easily test the cleaned up version and if feedback asks to solve something differently.
Looks like original authorship of Grazvydas Ignotas should be left, despite numerous changes by you (and apparently future cleanup by me).
My contribution is small. Mainly keep it in sync with changing kernel API.
Right? Other contributors could be mentioned in the commit message.
Yes.
Ah, before I forget: it may lack a device tree bindings document.
All others are either not mature enough for upstreaming or in some intermediate LKML review stage (in most cases there has been feedback but is not worked completely into version n+1 so it is difficult to define/describe the current status - except that it works for us).
I'm fine to dig feedback from history and to make some n+1's, when I'm done with nub driver.
One important driver is still empty and needs real driver development work:
http://git.goldelico.com/?p=gta04-kernel.git;a=shortlog;h=refs/heads/work/hn...
Looked interesting until I reviewed the datasheet PDF (of 25 pages), then I've realized that I have no idea what to do with this :) Everything is about electricity, no "registers i/o" to which I'm accustomed :)
-- Mit freundlichen Grüßen,
Michael Mrozek
OpenPandora GmbH Geschäftsführer: Michael Mrozek
Schäffbräustr. 11 85049 Ingolstadt Deutschland Tel.: 0841 / 990 5548 http://www.openpandora.de/ HRB 4879, Amtsgericht Ingolstadt
eMail: mrozek@openpandora.org
Am Mon, 13 Jun 2016 15:42:21 +0200 hat "H. Nikolaus Schaller" hns@goldelico.com geschrieben:
Well, maybe notaz can explain it better what he meant. But those different modes that are switched in userspace are not standard X :)
one more information about the nub/joystick driver.
While it DOES work, it's a bit of a hack and can be done in a better way. notaz (Grazvydas) suggested to change that driver so that the nubs report themselves as Input devices for X, so they can be more flexible and properly configured with the X Server.
They do present themselves as /dev/input/event* which is what X Server is looking for.
On 06/13/2016 04:54 PM, Michael Mrozek wrote:
Am Mon, 13 Jun 2016 15:42:21 +0200 hat "H. Nikolaus Schaller" hns@goldelico.com geschrieben:
Well, maybe notaz can explain it better what he meant. But those different modes that are switched in userspace are not standard X :)
one more information about the nub/joystick driver.
While it DOES work, it's a bit of a hack and can be done in a better way. notaz (Grazvydas) suggested to change that driver so that the nubs report themselves as Input devices for X, so they can be more flexible and properly configured with the X Server.
They do present themselves as /dev/input/event* which is what X Server is looking for.
Not this again. The way the nubs worked on pandora is about the worst possible option. There are almost no games out there that expect the controls to come from 4 seperate devices, which may disapear at any time because someone set them to a different mode. Also, the modes had no configuration options, other than what was hardcoded into the kernel.
I still think the best option is to just have any hardware devices show up as whatever they really are, and have a small input daemon running that grabs all of them, and outputs it into a single easily user configurable input device.
Having to run an input daemon is still preferable to having to add special input code to any application that needs to read from the nubs/buttons. And I think a daemon is already needed to handle the volume wheel anyway.
(There has already been a lot of discussion about this on the forums, and a few half written daemons exist)
Am 14.06.2016 um 14:46 schrieb aTc atc@k-n-p.org:
On 06/13/2016 04:54 PM, Michael Mrozek wrote:
Am Mon, 13 Jun 2016 15:42:21 +0200 hat "H. Nikolaus Schaller" hns@goldelico.com geschrieben:
Well, maybe notaz can explain it better what he meant. But those different modes that are switched in userspace are not standard X :)
Indeed no. X11 assumes mouse / pointer devices.
one more information about the nub/joystick driver.
While it DOES work, it's a bit of a hack and can be done in a better way. notaz (Grazvydas) suggested to change that driver so that the nubs report themselves as Input devices for X, so they can be more flexible and properly configured with the X Server.
They do present themselves as /dev/input/event* which is what X Server is looking for.
Not this again. The way the nubs worked on pandora is about the worst possible option. There are almost no games out there that expect the controls to come from 4 seperate devices, which may disapear at any time because someone set them to a different mode. Also, the modes had no configuration options, other than what was hardcoded into the kernel.
I still think the best option is to just have any hardware devices show up as whatever they really are, and have a small input daemon running that grabs all of them, and outputs it into a single easily user configurable input device.
How easy is it to integrate such a daemon into the X11 evdev driver which works out of the box?
Having to run an input daemon is still preferable to having to add special input code to any application that needs to read from the nubs/buttons. And I think a daemon is already needed to handle the volume wheel anyway.
Indeed - but I would not mix that with other input daemons since they have different latency requirements and differ in event driven vs. polling mode.
(There has already been a lot of discussion about this on the forums, and a few half written daemons exist) _______________________________________________ Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
On 06/14/2016 03:14 PM, H. Nikolaus Schaller wrote:
How easy is it to integrate such a daemon into the X11 evdev driver which works out of the box?
Shouldn't be that hard, most of the work is done by the kernels uinput module.
a few existing projects that use it :
http://pingus.seul.org/~grumbel/xboxdrv/ https://github.com/tuomasjjrasanen/python-uinput http://users.softlab.ntua.gr/~thkala/projects/evmapd/evmapd.html
Am 14.06.2016 um 15:30 schrieb aTc atc@k-n-p.org:
On 06/14/2016 03:14 PM, H. Nikolaus Schaller wrote:
How easy is it to integrate such a daemon into the X11 evdev driver which works out of the box?
Shouldn't be that hard, most of the work is done by the kernels uinput module.
a few existing projects that use it :
http://pingus.seul.org/~grumbel/xboxdrv/ https://github.com/tuomasjjrasanen/python-uinput http://users.softlab.ntua.gr/~thkala/projects/evmapd/evmapd.html
The last one looks quite straightforwards to translate evdev -> uinput
But it is quite old. So is it maintained? Do we have to manage it ourselves?
I would prefer if we can use standard (Debian) packages that are already maintained by someone instead of adding new things and requirements.
And, we might better start with something that works with standard X11 (and w/o additional daemons) and then add the specific things needed for joystick games etc.
BR, Nikolaus
On 06/14/2016 03:41 PM, H. Nikolaus Schaller wrote:
Am 14.06.2016 um 15:30 schrieb aTc atc@k-n-p.org:
On 06/14/2016 03:14 PM, H. Nikolaus Schaller wrote:
How easy is it to integrate such a daemon into the X11 evdev driver which works out of the box?
Shouldn't be that hard, most of the work is done by the kernels uinput module.
a few existing projects that use it :
http://pingus.seul.org/~grumbel/xboxdrv/ https://github.com/tuomasjjrasanen/python-uinput http://users.softlab.ntua.gr/~thkala/projects/evmapd/evmapd.html
The last one looks quite straightforwards to translate evdev -> uinput
But it is quite old. So is it maintained? Do we have to manage it ourselves?
I would prefer if we can use standard (Debian) packages that are already maintained by someone instead of adding new things and requirements.
Me too, unfortunately I haven't been able to find something for our use case. All of the existing daemons only expect to take input from a single device, instead of grabbing from multiple devices at the same time. xboxdrv comes closest, but still misses a few things.
On Tue, Jun 14, 2016 at 02:46:37PM +0200, aTc wrote:
I still think the best option is to just have any hardware devices show up as whatever they really are, and have a small input daemon running that grabs all of them, and outputs it into a single easily user configurable input device.
This would be the simplest for mainlining the kernel driver. But natively nub is just a joystick as I see; it's mostly fine but Pyra lacks ubiquitous touchpad/trackpoint, so something to substitute mouse buttons and scrolling wheel(s) would be good. I guess a userspace daemon could cope with this, e.g. handling events from one nub in trackpoint fashion, and from the other one in scrolling wheel + mousebuttons fashion, but the latter conversion feels somewhat unnatural. Also I wonder if such daemon could assist to not only X11, but alsoconsole based applications which handle scrolling wheel events.
Am 14.06.2016 um 16:20 schrieb Andrey Utkin andrey_utkin@fastmail.com:
On Tue, Jun 14, 2016 at 02:46:37PM +0200, aTc wrote:
I still think the best option is to just have any hardware devices show up as whatever they really are, and have a small input daemon running that grabs all of them, and outputs it into a single easily user configurable input device.
This would be the simplest for mainlining the kernel driver. But natively nub is just a joystick as I see; it's mostly fine but Pyra lacks ubiquitous touchpad/trackpoint, so something to substitute mouse buttons and scrolling wheel(s) would be good.
The nubs have a button in the middle. They are gpio-buttons and mapped to send left- and right mouse events. This appears to work in the current kernel because X11 does already integrate all input devices it finds.
Well, it could be possible to add gpio-button handling to the driver. But it would duplicate what gpio-button can already do.
I guess a userspace daemon could cope with this, e.g. handling events from one nub in trackpoint fashion, and from the other one in scrolling wheel + mousebuttons fashion, but the latter conversion feels somewhat unnatural. Also I wonder if such daemon could assist to not only X11, but alsoconsole based applications which handle scrolling wheel events.
Hm. Again it looks like you urgently need a device to experiment for the best modes.
Means: I will stop at this point and focus on getting the developer prototypes finalized (they had some wires changed last week and this needs to be tested / fixed).
BR, Nikolaus
Am 13.06.2016 um 15:15 schrieb Andrey Utkin andrey_utkin@fastmail.com:
On Mon, Jun 13, 2016 at 02:11:53PM +0200, H. Nikolaus Schaller wrote:
I only came up with the nub/joystick driver which works, but has not yet been pushed at all:
http://git.goldelico.com/?p=gta04-kernel.git;a=shortlog;h=refs/heads/work/hn...
This looks like a good task for me. Thanks.
So I would say you could try to clean up the as5013 driver first and then try to get it upstream. A minor problem is that you can't easily test the cleaned up version and if feedback asks to solve something differently.
Looks like original authorship of Grazvydas Ignotas should be left, despite numerous changes by you (and apparently future cleanup by me). Right? Other contributors could be mentioned in the commit message.
All others are either not mature enough for upstreaming or in some intermediate LKML review stage (in most cases there has been feedback but is not worked completely into version n+1 so it is difficult to define/describe the current status - except that it works for us).
I'm fine to dig feedback from history
It is not only in history but in local code and commit files. I.e. not optimal for handover.
and to make some n+1's, when I'm done with nub driver.
One important driver is still empty and needs real driver development work:
http://git.goldelico.com/?p=gta04-kernel.git;a=shortlog;h=refs/heads/work/hn...
Looked interesting until I reviewed the datasheet PDF (of 25 pages), then I've realized that I have no idea what to do with this :) Everything is about electricity, no "registers i/o" to which I'm accustomed :)
You can forget about the datasheet :)
The driver just needs to control one gpio in the right moments.
BR, Nikolaus