**** BEGIN LOGGING AT Sat Jul 18 02:59:59 2015
Jul 18 12:45:49 <Derecho> right I've been playing with trying to get a usb gadget hid driver working (I want to emulate a keyboard with the bbb) but I'm not progressing well
Jul 18 12:46:04 <Derecho> I'm compiling my own kernel+fs, that's all sorted fine
Jul 18 12:47:09 <Derecho> after much reading I've basically replaced hid.c with this one: https://github.com/csimmonds/g_hid-demo
Jul 18 12:48:01 <Derecho> as it seemed to be a quick way of testing whether it works and it's just adding the contents of the gadget_hid.txt to g_hid which you want to load anyway for this (right?)
Jul 18 12:48:31 <Derecho> but, now, while before adding this code I would just get a "can't load module ... no such device", I get a nice stacktrace beforehand.
Jul 18 12:48:42 <Derecho> so I'm a bit puzzled as where to go from here
Jul 18 12:48:50 <Derecho> did I take the wrong approach?
Jul 18 12:49:26 <Derecho> I'm running linux 3.14.34 on it btw
Jul 18 12:58:08 <Derecho> there doesn't really seem to be a clear concensus on how to get that keyboard emulation g_hid code working, other than reports from people who either do have it working perfectly or cannot get it to work
Jul 18 12:58:32 <Derecho> I could imagine that something bbb-specific needs to happen to it, but the guy in that repo used it on his bbb fine so..
Jul 18 12:59:03 <Derecho> I've also seen mention of gadgetfs, is that something I should favour over this approach?
Jul 18 13:43:01 <_av500_> gadgetfs is is you want to do it in user space
Jul 18 13:43:11 <_av500_> it exposes the devce endpoints to user space
Jul 18 13:43:21 <_av500_> so thats one approach
Jul 18 13:44:11 <_av500_> or there is g_hid
Jul 18 13:44:23 <Derecho> I'll go with the approach that actually works haha
Jul 18 13:44:44 <Derecho> eventually I'll need to feed the keyboard even data from userspace to it, but I understand that's possible in both scenarios
Jul 18 13:44:49 <Derecho> event*
Jul 18 13:46:31 <Derecho> I have to admit I have limited experience with usb dev. I've played with reverse engineering a protocol once and talking to a device using libusb, but I wasn't doing that on my own and that's different from gadget dev
Jul 18 13:46:32 <_av500_> hid.c here https://github.com/csimmonds/g_hid-demo
Jul 18 13:46:42 <_av500_>  looks very much like the hid.c in the kernel anyway
Jul 18 13:46:45 <Derecho> yes that's the one I linked to, that one throws a stacktrace.
Jul 18 13:46:55 <_av500_> well, its for angstrom
Jul 18 13:47:11 <_av500_> I guess it might need some love with more modern kernels
Jul 18 13:47:18 <_av500_> why not use g_hid ?
Jul 18 13:47:26 <_av500_> the one that comes with your kernel
Jul 18 13:47:44 <_av500_> linux/drivers/usb/gadget/hid.c
Jul 18 13:48:11 <Derecho> the one that comes with my kernel is basically that one in the repo but without the struct and calls for it that are documented in gadget_hid.txt
Jul 18 13:48:20 <Derecho> so I think that's sort of an "empty" driver?
Jul 18 13:48:40 <Derecho> either way, stock or that csimmonds one, it ends with a "no such device" message upon loading the driver
Jul 18 13:48:55 <Derecho> with the difference the csimmonds one throwing a stacktrace beforehand
Jul 18 13:50:14 <_av500_> yes, its just platform driver
Jul 18 13:50:57 <_av500_> Derecho: there is a stock gadget driver loaded by default
Jul 18 13:51:03 <_av500_> you might have to unload that one
Jul 18 13:51:07 <_av500_> see with lsmod
Jul 18 13:51:13 <Derecho> not on my own kernel
Jul 18 13:51:14 <_av500_> if y<ou have other g_
Jul 18 13:51:25 <Derecho> but yes on the stock debian on the flash there is
Jul 18 13:51:29 <_av500_> ok
Jul 18 13:52:23 <Derecho> was I too adventourous with compiling my own kernel+fs image for this? it seemed like a step #1 for making a reproducable project
Jul 18 13:52:32 <_av500_> well
Jul 18 13:52:38 <Derecho> the fs is much slimmer and the kernel is newer
Jul 18 13:52:48 <_av500_> you can also just take a ready debian
Jul 18 13:52:56 <_av500_> and go from there
Jul 18 13:53:02 <Derecho> the stock one?
Jul 18 13:53:04 <_av500_> sure
Jul 18 13:53:06 <_av500_> why not?
Jul 18 13:53:09 <Derecho> it just looks messier.
Jul 18 13:53:11 <Devastator> good morning, does beaglebone black rev c is still in production? I'm trying to buy one from garagelab store but I'm seeing it out of stock for awhile..
Jul 18 13:53:25 <_av500_> Devastator: BBB is stil in prod
Jul 18 13:53:29 <Derecho> for example, with having to unload the gadget drivers that are already active
Jul 18 13:53:38 <_av500_> the spiel is to order
Jul 18 13:53:54 <Devastator> _av500_ thank you!
Jul 18 13:53:56 <_av500_> they sell out fast, so waiting for stock is often useless
Jul 18 13:54:20 <Devastator> hum.. I will try to back order then
Jul 18 13:54:35 <_av500_> or see other vendors
Jul 18 13:55:03 <Devastator> problem is some doesn't ship internationally hehe
Jul 18 13:55:33 <Devastator> my idea is to buy one to learn how to build embedded linux devices
Jul 18 13:55:43 <Devastator> don't know if I'm on the right track though
Jul 18 14:02:37 <Derecho> think I may have found something regarding that hid.c
Jul 18 14:03:19 <Derecho> so, this is what I get upon trying to load csimmond's driver: http://s.drk.sc/csBjAS/
Jul 18 14:03:33 <Derecho> the stacktrace was puzzling me as I recognised very little, but I spotted the unregister just now
Jul 18 14:03:53 <Derecho> and that's being called from either line 328 or 329
Jul 18 14:04:07 <Derecho> because there's a message beforehand:
Jul 18 14:04:17 <Derecho> usb_composite_probe failed: -19
Jul 18 14:08:09 <Derecho> looks like -19 means ENODEV
Jul 18 14:08:12 <Derecho> No such device
Jul 18 14:08:36 <Derecho> I'm really on the edge here with what I understand about this and what I don't
Jul 18 14:08:49 <Derecho> but it seems silly that it's complaining about not finding a device that it is itself supposed to become
Jul 18 14:09:49 <Derecho> so that's basically the "modprobe: can't load module g_hid (kernel/drivers/usb/gadget/g_hid.ko): No such device" at the bottom
Jul 18 14:10:01 <Derecho> which it throws with the stock hid.c too
Jul 18 14:17:29 <_av500_> Device 'hidg.0' does not have a release() function, it is broken and must be fixed.
Jul 18 14:17:36 <_av500_> this is quite clear error desc
Jul 18 14:18:27 <Derecho> yes but that is triggered after the device fails to load
Jul 18 14:21:20 <_av500_> right
Jul 18 14:21:48 <Derecho> I mean, I agree that that should be neatly handled, but it doesn't seem to be the cause for the thing not to work
Jul 18 14:23:40 <_av500_> status = usb_composite_probe(&hidg_driver);
Jul 18 14:23:43 <_av500_> this fails
Jul 18 14:24:19 <_av500_> no idea why
Jul 18 14:25:47 <Derecho> yeah :(
Jul 18 14:26:39 <Derecho> that's already in the hid.c originally
Jul 18 14:26:41 <Derecho> how can that be wrong?
Jul 18 14:28:22 <Derecho> it's just so incredibly frustrating that if I google, most issues people seem to be having is when they are past getting this example to work and are trying something fancy and custom
Jul 18 14:28:30 <Derecho> this is just not supposed to fail so soon
Jul 18 14:28:38 <Derecho> and I know too little to know why
Jul 18 14:34:16 <_av500_> so same error with stock hid.c?
Jul 18 14:34:30 <Derecho> well, sort of
Jul 18 14:34:34 <Derecho> the very last line, yes
Jul 18 14:34:41 <_av500_> and if you try with stock debian?
Jul 18 14:34:50 <Derecho> the usb_composite_probe call is from the extended one
Jul 18 14:35:16 <Derecho> I am trying to load the stock g_hid module on the stock debian but I can't seem to get that done as that g_multi is sitting in the way
Jul 18 14:35:41 <Derecho> told modprobe to blacklist it but it seems not to listen to me
Jul 18 14:36:39 <Derecho> if I do it *with* the g_multi loaded I get Operation not permitted
Jul 18 14:36:44 <Derecho> oh hang on
Jul 18 14:36:50 <Derecho> No such device.
Jul 18 14:37:08 <Derecho> so stock debian seems to error the same way as custom kernel+fs with stock hid.c
Jul 18 14:37:33 <Derecho> and the extended hid.c errors on loading the hid gadget I think because of the very same error
Jul 18 14:44:37 <_av500_> ok
Jul 18 14:45:10 <_av500_> Derecho: you might try if Peter koorsgard is over in #buildroot
Jul 18 14:45:15 <_av500_> dont know the nick
Jul 18 14:45:27 <_av500_> since he is listed as one of the authors
Jul 18 14:45:30 <_av500_> maybe he has an idea
Jul 18 14:45:51 <Derecho> all right, I'll try that
Jul 18 14:53:54 <Derecho> zhmm none of the nicks really stand out
Jul 18 15:05:57 <Derecho> so _av500_ have you got any prior experience with this or...?
Jul 18 15:06:24 <Derecho> I'm willing to change approach, I just need it to start working so I can start on my part of the code for this
Jul 18 15:15:17 <_av500_> Derecho: the nick is Jacmet
Jul 18 17:29:59 <Derecho> right so I'm looking at the gadgetfs approach now
Jul 18 17:30:04 <Derecho> but I can't mount gadgetfs for some reason
Jul 18 17:30:11 <Derecho> again, neither in stock debian nor in my own image
Jul 18 17:31:08 <Derecho> I really don't understand why I have to fight the board to do something that's supposed to work. and I can't start on my own code before this works.
Jul 18 17:37:56 <_av500_> there is a big field of "supposed to work" inside the linux kernel
Jul 18 18:01:13 <Derecho> [   35.237671] couldn't find an available UDC
Jul 18 18:01:33 <Derecho> that's this: http://lxr.free-electrons.com/source/drivers/usb/gadget/udc/udc-core.c#L471
Jul 18 18:02:10 <Derecho> I don't even know what a UDC is, but apperantly I'm missing one.
Jul 18 22:28:14 <foundatron_> Hi, I'm trying to set up my fstab entry to automount my uSD card to specific mount point and running into issues. If i boot with the uSD card in (which just ahas an .ini file on it), the emmc gets mounted at that mount point rather than the uSD card.
Jul 18 22:29:08 <foundatron_> it's like the emmc flipbs between being  /dev/mmcblk1p1 and /dev/mmcblk0p1 dpending on whther or not an uSD is present
Jul 18 22:30:16 <foundatron_> is there way to always target the uSD in your ftsab file
Jul 18 22:30:17 <foundatron_> ?
Jul 18 22:30:29 <foundatron_> This is what i have right now https://gist.github.com/foundatron/847a8b81a74ded867c89#file-fstab-L11
Jul 18 22:37:38 <rob_w> yeah ye old mmc numbering problem
Jul 18 22:38:16 <rob_w> there is a kernel patch which will number the mmc always the same
Jul 18 23:01:09 <foundatron_> i see the emmc flasher assigns a uuid
Jul 18 23:01:12 <foundatron_> to emmc
Jul 18 23:01:31 <foundatron_> but for the sd card, wouldn't that change based on what sd card you used
Jul 18 23:01:48 <foundatron_> I was just looking up using /by-id/ to use a hardware id
Jul 18 23:02:18 <foundatron_> but I don't know if that would change change or not with each sd card
Jul 19 00:54:09 <stt_michael> you'll need mdev or something to populate by-id or by-uuid
Jul 19 00:54:16 <stt_michael> ie. an initramfs
**** ENDING LOGGING AT Sun Jul 19 02:59:58 2015