Re: [beagleboard] HID on BBB with 4.9 kernel
On Thu, 12/22/16, William Hermans wrote: Subject: Re: [beagleboard] HID on BBB with 4.9 kernel To: beagleboard@googlegroups.com Date: Thursday, December 22, 2016, 1:13 AM On Wed, Dec 21, 2016 at 1:56 PM, roboknight wrote: On Tuesday, December 20, 2016 at 3:27:44 PM UTC-5, William Hermans wrote: On Tue, Dec 20, 2016 at 10:02 AM, roboknight wrote: At the underlined point, I believe ep->desc is NULL because using the kernel and an arm objdump variant,I located the assembly that is causing the NULL dereference. Inside of usb_endpoing_dir_out, it tries todereference ep->desc, but ep->desc must be NULL otherwise things would likely go swimmingly. The problemis, I don't know what would cause ep->desc == NULL? Whatever causes this (and it might be related toa function called "usb_gadget_ep_match_desc") I'd like to know because knowing might tell me how to fixwhatever it is I'm doing wrong or maybe patch the code so that things might work. I'm hoping someone knowledgeable about am335x USB can help here, or maybe let me know what I'm missingin my HID configuration. The above configuration steps may not work, however, some python code I had previouslyalso fails to function. It might even be possible that I just need to use the regular HID driver and not one based onlibcomposite. Thanks for reading this. Hopefully there are some answers. So, I'm not a USB composite framework expert. I only started reading about it last night for another reason. A lot of what you're stating in your last couple paragraphs here do not make sense to me. What I'm reading from your post is that the end point descriptor must be NULL. but you're not sure why it's NULL . . .yadda yadda yadda . . .That should not be true. The yadda yadda yadda was kind of the point. I actually have looked into it further and the only way that reference would actually be null is if the autoepconfig function couldn't choose any available endpoint because none of them matched the correct criteria. I'm not sure where I'm supposed to SET UP the appropriate criteria, hence the question, and the details. My first impression after looking through that code is user error. Simply because a function that's being used requires a valid end point descriptor reference as an argument, and that argument is NULL. Which tells me that whole "object" was never instantiated in the first place. those objects aren't "instantiated". They are actually endpoints that are "built-in" (you can see one for full-speed, high-speed, and now super-speed). One of the endpoints is supposed to get selected based on an appropriate description. Mine probably doesn't match or I haven't set one, hence it doesn't work. But I don't see anywhere where I can actually SPECIFY the necessary things in configfs... Maybe you just can't build a HID device with configfs right now? Or maybe something changed. Either way, I'm researching the answer to that question so I can figure out what I really need to do. Maybe there is another way I can configure a HID driver, not using configfs. The things I was able to do in the 3.13.xx kernel don't seem to work with this kernel either, or I don't have them set up correctly, hence I figured the "new" or current method was to use configfs. But maybe this isn't the case. I have tried to get the "latest" from the TI repo, and the results are the same. So I'm guessing that my kernel configuration was probably okay, but somehow I'm not doing something right with configfs, or configfs doesn't work for HID devices yet (I don't know if I believe that, but its possible). At any rate, I've not managed to get it working yet. Yeah that's all I was really saying. Sometimes *things* like to be done in a certain order, or maybe a configfs step that was required was missed ? Theres a LWN article I was reading the other day, that seems to be pretty full of information. However, the "walk-thru" only talks about re-implementing the mass storage gadget using USB composite. https://lwn.net/Articles/395712/ I've also seen a few presentation type PDF's out there. I do not really know enough about the framework to know how useful these are though. Passed that, I have not yet seen one for HiD. Although . . . you know what, I think DR. Phil Polstra did a presentation on emulating a keyboard using HiD USB device, and I do think he used configfs . . . However he may have used an older kernel as well. I'll tell you what though, even though I'm not necessarily interested in creating an HiD device. I have interest in this whole composite framework. SO I'll do
Re: [beagleboard] HID on BBB with 4.9 kernel
On Wed, Dec 21, 2016 at 1:56 PM, roboknight wrote: > > > On Tuesday, December 20, 2016 at 3:27:44 PM UTC-5, William Hermans wrote: >> >> >> >> On Tue, Dec 20, 2016 at 10:02 AM, roboknight wrote: >> >> At the underlined point, I believe ep->desc is NULL because using the >> kernel and an arm objdump variant, >>> >>> I located the assembly that is causing the NULL dereference. Inside of >>> usb_endpoing_dir_out, it tries to >>> dereference ep->desc, but ep->desc must be NULL otherwise things would >>> likely go swimmingly. The problem >>> is, I don't know what would cause ep->desc == NULL? Whatever causes >>> this (and it might be related to >>> a function called "usb_gadget_ep_match_desc") I'd like to know because >>> knowing might tell me how to fix >>> whatever it is I'm doing wrong or maybe patch the code so that things >>> might work. >>> >>> I'm hoping someone knowledgeable about am335x USB can help here, or >>> maybe let me know what I'm missing >>> in my HID configuration. The above configuration steps may not work, >>> however, some python code I had previously >>> also fails to function. It might even be possible that I just need to >>> use the regular HID driver and not one based on >>> libcomposite. >>> >>> Thanks for reading this. Hopefully there are some answers. >>> >> >> So, I'm not a USB composite framework expert. I only started reading >> about it last night for another reason. A lot of what you're stating in >> your last couple paragraphs here do not make sense to me. What I'm reading >> from your post is that the end point descriptor must be NULL. but you're >> not sure why it's NULL . . .yadda yadda yadda . . .That should not be true. >> > > The yadda yadda yadda was kind of the point. I actually have looked into > it further and the only way that reference would actually be null is if the > autoepconfig function couldn't choose any available endpoint because none > of them matched the correct criteria. I'm not sure where I'm supposed to > SET UP the appropriate criteria, hence the question, and the details. > >> >> My first impression after looking through that code is user error. Simply >> because a function that's being used requires a valid end point descriptor >> reference as an argument, and that argument is NULL. Which tells me that >> whole "object" was never instantiated in the first place. >> > those objects aren't "instantiated". They are actually endpoints that are > "built-in" (you can see one for full-speed, high-speed, and now > super-speed). One of the endpoints is supposed to get selected based on an > appropriate description. Mine probably doesn't match or I haven't set one, > hence it doesn't work. But I don't see anywhere where I can actually > SPECIFY the necessary things in configfs... Maybe you just can't build a > HID device with configfs right now? Or maybe something changed. Either > way, I'm researching the answer to that question so I can figure out what I > really need to do. Maybe there is another way I can configure a HID > driver, not using configfs. > > The things I was able to do in the 3.13.xx kernel don't seem to work with > this kernel either, or I don't have them set up correctly, hence I figured > the "new" or current method was to use configfs. But maybe this isn't the > case. > > I have tried to get the "latest" from the TI repo, and the results are the > same. So I'm guessing that my kernel configuration was probably okay, but > somehow I'm not doing something right with configfs, or configfs doesn't > work for HID devices yet (I don't know if I believe that, but its > possible). At any rate, I've not managed to get it working yet. > Yeah that's all I was really saying. Sometimes *things* like to be done in a certain order, or maybe a configfs step that was required was missed ? Theres a LWN article I was reading the other day, that seems to be pretty full of information. However, the "walk-thru" only talks about re-implementing the mass storage gadget using USB composite. https://lwn.net/Articles/395712/ I've also seen a few presentation type PDF's out there. I do not really know enough about the framework to know how useful these are though. Passed that, I have not yet seen one for HiD. Although . . . you know what, I think DR. Phil Polstra did a presentation on emulating a keyboard using HiD USB device, and I do think he used configfs . . . However he may have used an older kernel as well. I'll tell you what though, even though I'm not necessarily interested in creating an HiD device. I have interest in this whole composite framework. SO I'll do some searching on my own, and let you know what I find. I may even just start out with an HiD "thing" just to get my feet wet. Maybe you've seen these already ? I'm not sure if any, or all of this is already know to you, but here goes . . . Matt Porter: http://events.linuxfoundation.org/sites/events/files/slides/USB%20Gadget%20Configfs%20API_0.pdf Andrzej Pietrasiewicz: http
Re: [beagleboard] HID on BBB with 4.9 kernel
On Tuesday, December 20, 2016 at 3:27:44 PM UTC-5, William Hermans wrote: > > > > On Tue, Dec 20, 2016 at 10:02 AM, roboknight > wrote: > > At the underlined point, I believe ep->desc is NULL because using the > kernel and an arm objdump variant, >> >> I located the assembly that is causing the NULL dereference. Inside of >> usb_endpoing_dir_out, it tries to >> dereference ep->desc, but ep->desc must be NULL otherwise things would >> likely go swimmingly. The problem >> is, I don't know what would cause ep->desc == NULL? Whatever causes this >> (and it might be related to >> a function called "usb_gadget_ep_match_desc") I'd like to know because >> knowing might tell me how to fix >> whatever it is I'm doing wrong or maybe patch the code so that things >> might work. >> >> I'm hoping someone knowledgeable about am335x USB can help here, or maybe >> let me know what I'm missing >> in my HID configuration. The above configuration steps may not work, >> however, some python code I had previously >> also fails to function. It might even be possible that I just need to >> use the regular HID driver and not one based on >> libcomposite. >> >> Thanks for reading this. Hopefully there are some answers. >> > > So, I'm not a USB composite framework expert. I only started reading about > it last night for another reason. A lot of what you're stating in your last > couple paragraphs here do not make sense to me. What I'm reading from your > post is that the end point descriptor must be NULL. but you're not sure why > it's NULL . . .yadda yadda yadda . . .That should not be true. > The yadda yadda yadda was kind of the point. I actually have looked into it further and the only way that reference would actually be null is if the autoepconfig function couldn't choose any available endpoint because none of them matched the correct criteria. I'm not sure where I'm supposed to SET UP the appropriate criteria, hence the question, and the details. > > My first impression after looking through that code is user error. Simply > because a function that's being used requires a valid end point descriptor > reference as an argument, and that argument is NULL. Which tells me that > whole "object" was never instantiated in the first place. > those objects aren't "instantiated". They are actually endpoints that are "built-in" (you can see one for full-speed, high-speed, and now super-speed). One of the endpoints is supposed to get selected based on an appropriate description. Mine probably doesn't match or I haven't set one, hence it doesn't work. But I don't see anywhere where I can actually SPECIFY the necessary things in configfs... Maybe you just can't build a HID device with configfs right now? Or maybe something changed. Either way, I'm researching the answer to that question so I can figure out what I really need to do. Maybe there is another way I can configure a HID driver, not using configfs. The things I was able to do in the 3.13.xx kernel don't seem to work with this kernel either, or I don't have them set up correctly, hence I figured the "new" or current method was to use configfs. But maybe this isn't the case. I have tried to get the "latest" from the TI repo, and the results are the same. So I'm guessing that my kernel configuration was probably okay, but somehow I'm not doing something right with configfs, or configfs doesn't work for HID devices yet (I don't know if I believe that, but its possible). At any rate, I've not managed to get it working yet. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/1f8e3b22-f8b9-4b9e-88a4-5fdc077e6cc6%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] HID on BBB with 4.9 kernel
To clarify my response somewhat. It does seem to me that you're using configfs to create your HID device. I get that, so you're not modifying the kernel module, or anything like that. What I'm saying is that perhaps things have changed in how configfs is used, in order to setup a composite HID device. Or the kernel module code has reverted to an earlier state that was previously non functional. When moving to 4.9.x. This( the later ) seems to happen a lot in these "cutting edge" kernels. Which is why I personally sty away from them for a few weeks at least. I'm also not sure who would need to be contacted for this type of situation. But it's likely the maintainer for this part of the kernel. On Tue, Dec 20, 2016 at 1:27 PM, William Hermans wrote: > > > On Tue, Dec 20, 2016 at 10:02 AM, roboknight wrote: > > At the underlined point, I believe ep->desc is NULL because using the > kernel and an arm objdump variant, >> >> I located the assembly that is causing the NULL dereference. Inside of >> usb_endpoing_dir_out, it tries to >> dereference ep->desc, but ep->desc must be NULL otherwise things would >> likely go swimmingly. The problem >> is, I don't know what would cause ep->desc == NULL? Whatever causes this >> (and it might be related to >> a function called "usb_gadget_ep_match_desc") I'd like to know because >> knowing might tell me how to fix >> whatever it is I'm doing wrong or maybe patch the code so that things >> might work. >> >> I'm hoping someone knowledgeable about am335x USB can help here, or maybe >> let me know what I'm missing >> in my HID configuration. The above configuration steps may not work, >> however, some python code I had previously >> also fails to function. It might even be possible that I just need to >> use the regular HID driver and not one based on >> libcomposite. >> >> Thanks for reading this. Hopefully there are some answers. >> > > So, I'm not a USB composite framework expert. I only started reading about > it last night for another reason. A lot of what you're stating in your last > couple paragraphs here do not make sense to me. What I'm reading from your > post is that the end point descriptor must be NULL. but you're not sure why > it's NULL . . .yadda yadda yadda . . .That should not be true. > > My first impression after looking through that code is user error. Simply > because a function that's being used requires a valid end point descriptor > reference as an argument, and that argument is NULL. Which tells me that > whole "object" was never instantiated in the first place. > -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CALHSORo8r8PzwZBAPtxsyMabE3fAhYzGttGXvM01pdAw2vBLWA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] HID on BBB with 4.9 kernel
On Tue, Dec 20, 2016 at 10:02 AM, roboknight wrote: At the underlined point, I believe ep->desc is NULL because using the kernel and an arm objdump variant, > > I located the assembly that is causing the NULL dereference. Inside of > usb_endpoing_dir_out, it tries to > dereference ep->desc, but ep->desc must be NULL otherwise things would > likely go swimmingly. The problem > is, I don't know what would cause ep->desc == NULL? Whatever causes this > (and it might be related to > a function called "usb_gadget_ep_match_desc") I'd like to know because > knowing might tell me how to fix > whatever it is I'm doing wrong or maybe patch the code so that things > might work. > > I'm hoping someone knowledgeable about am335x USB can help here, or maybe > let me know what I'm missing > in my HID configuration. The above configuration steps may not work, > however, some python code I had previously > also fails to function. It might even be possible that I just need to use > the regular HID driver and not one based on > libcomposite. > > Thanks for reading this. Hopefully there are some answers. > So, I'm not a USB composite framework expert. I only started reading about it last night for another reason. A lot of what you're stating in your last couple paragraphs here do not make sense to me. What I'm reading from your post is that the end point descriptor must be NULL. but you're not sure why it's NULL . . .yadda yadda yadda . . .That should not be true. My first impression after looking through that code is user error. Simply because a function that's being used requires a valid end point descriptor reference as an argument, and that argument is NULL. Which tells me that whole "object" was never instantiated in the first place. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CALHSORrqej0%2BJ3L3sSF4fP_o%2BN%2BF613B0cm1ot8m8ndhh_8yAw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
