<viric>
I just buy a laser mouse at the nearest shop
xiangfu_ has joined #qi-hardware
<viric>
if within two years it breaks, I return it
<viric>
and get one new for free
<unclouded>
nice shop. I've also got a M905, which is so beautifully made that you'd hardly believe that it was made by the same people who put the appalling G500s that went wrong
<unclouded>
s/put/made/
<qi-bot>
unclouded meant: "nice shop. I've also got a M905, which is so beautifully made that you'd hardly believe that it was made by the same people who made the appalling G500s that went wrong"
<wpwrak>
i guess i'll get another M200 +/- 15. the fancier models all may need a special setup on the pc.
<unclouded>
the M905 doesn't. The unifying feature doesn't work on Linux apparently but just using as a normal USB mouse works fine
<unclouded>
it does really work on glass tabletops and mirrors too
kanzure has joined #qi-hardware
<wpwrak>
my my desk's solid wood. any at no risk of getting too clean for the mouse to have something to recognize :)
<viric>
I always use a mouse carpet, with a textile-like surface.
viric has quit [Ping timeout: 240 seconds]
viric has joined #qi-hardware
kanzure has quit [Ping timeout: 240 seconds]
<wpwrak>
hmm, have to add an n-FET to the card power switch. else, it'll go "always on" when the battery gets low enough that Vbat + the FET's threshold voltage < 3.3 V (+ margin)
<wpwrak>
with the threshold as low as 0.45 V, that can happen relatively easily
<wpwrak>
it's good that there's plenty of room for this kind of rework under the OLED ;-)
kanzure has joined #qi-hardware
zhai has joined #qi-hardware
<larsc>
d
<larsc>
ups
pcercuei has joined #qi-hardware
zhai has quit [Quit: Leaving.]
porchaso0 has joined #qi-hardware
porchao has quit [Ping timeout: 256 seconds]
arossdotme has joined #qi-hardware
zhai has joined #qi-hardware
porchao has joined #qi-hardware
porchaso0 has quit [Read error: Connection reset by peer]
porchaso0 has joined #qi-hardware
porchao has quit [Read error: Connection reset by peer]
<larsc>
does anybody happen to know by chance what populates /dev/ on ubuntu these days? Is this done by upstart?
<pcercuei>
devtmpfs
<larsc>
hm, not on my machine, strage
<viric>
devtmpfs is very old
<viric>
udev does
<pcercuei>
no
<pcercuei>
udev requires devtmpfs
<viric>
mh
<viric>
ok, you win.
<viric>
I've devtmpfs here, but not ubuntu.
<pcercuei>
devfs is old, devtmpfs is not
<viric>
none on /dev type devtmpfs (rw,relatime,size=202716k,nr_inodes=497343,mode=755)
<viric>
200MB. looks like too much.
<pcercuei>
larsc:
<pcercuei>
cat /sys/kernel/uevent_helper
<larsc>
/sbin/hotplug
<pcercuei>
on my Debian, it doesn't return anything (because it uses devtmpfs)
<pcercuei>
maybe it's upstart then
zhai has quit [Quit: Leaving.]
<larsc>
but I have no /sbin/hotplug on my system...
<pcercuei>
and /dev is tmpfs?
<larsc>
no
<larsc>
realfs
<pcercuei>
ugh
<pcercuei>
I have no idea what "realfs" is
<larsc>
non-tmp fs ;)
<larsc>
there is nothing special mounted at /dev
<pcercuei>
/sbin/hotplug might exist... inside the initramfs
<larsc>
hm, which I do not have
<pcercuei>
why do you use ubuntu anyway? :o
<larsc>
linaro ubuntu
<larsc>
on one of the arm boards
porchao has joined #qi-hardware
zhai has joined #qi-hardware
porchaso0 has quit [Read error: Connection reset by peer]
zhai has quit [Client Quit]
wolfspraul has quit [Ping timeout: 268 seconds]
zhai has joined #qi-hardware
rz2k has joined #qi-hardware
porchaso0 has joined #qi-hardware
porchao has quit [Read error: Connection reset by peer]
woakas has joined #qi-hardware
kilae has joined #qi-hardware
arossdotme has quit [Ping timeout: 256 seconds]
paul_boddie has joined #qi-hardware
<paul_boddie>
Anyone here have any experience with Linux cdc_adm and serial-over-USB?
<paul_boddie>
I saw that wpwrak had his name on some Openmoko software of that nature. ;-)
<larsc>
I used it back in the openmoko days
<paul_boddie>
Did you ever experience problems with the device it created? Not the problem half the Internet has with modem-manager wanting to own it, but with the driver not apparently listening on the IN endpoint.
* paul_boddie
notes that Amarok on KDE 4 is such a joke these days. Let's not play music any more, then!
<wpwrak>
use mocp :)
<paul_boddie>
If KDE were a reality show, half of the applications would have been voted off in KDE season 4.
<paul_boddie>
With regard to cdc_acm, I'm trying out some AVR USB stuff that times out when trying to send to an IN endpoint, and I wondered if there was some known issues with the cdc_acm driver.
<paul_boddie>
s/IN endpoint/IN endpoint on the host/
<qi-bot>
paul_boddie meant: "With regard to cdc_acm, I'm trying out some AVR USB stuff that times out when trying to send to an IN endpoint on the host, and I wondered if there was some known issues with the cdc_acm driver."
<paul_boddie>
s/was some/were some/
<qi-bot>
paul_boddie meant: "With regard to cdc_acm, I'm trying out some AVR USB stuff that times out when trying to send to an IN endpoint on the host, and I wondered if there were some known issues with the cdc_acm driver."
viric has quit [Ping timeout: 240 seconds]
<DocScrutinizer05>
qi-bot, the better edlin
<paul_boddie>
Yes, the Internet can still learn from the "old school" tools.
<paul_boddie>
DocScrutinizer05: Was entertained/appalled by some of the messages on the Neo900 Maemo talk thread.
<paul_boddie>
The mental model of how hardware gets to the shops seems to involve pixies and unicorns for some people. ;-)
<DocScrutinizer05>
yep
<paul_boddie>
Or a secret Nokia factory still producing the devices in stealth mode and giving them away because they aren't allowed to sell them any more.
<paul_boddie>
Being forced to do so by an armed unicorn.
<DocScrutinizer05>
the same unicorn that fires his shrink-gun at the chips
<larsc>
paul_boddie: never had any problems with the driver
<paul_boddie>
larsc: OK. Thanks for the negative result. ;-)
viric has joined #qi-hardware
<larsc>
it's probably some kind of combination between avr and driver
<paul_boddie>
Yes, reading the driver source code can be a real eye-opener sometimes.
<paul_boddie>
The device gets created but the AVR thinks its FIFO isn't ready for sending. The weird thing is that I tried an example using HID events and that works.
* paul_boddie
ends up learning useless things about USB again, this time for AVR...
<larsc>
so you are in control of the AVR code?
<paul_boddie>
Yes. I have been playing with it, even removing the CDC stuff and trying to make it behave like a vanilla serial device (using usbserial instead).
<paul_boddie>
Is there anything special I have to do when using these /dev/ttyACM* or /dev/ttyUSB* things?
<larsc>
no
<paul_boddie>
With the ACM stuff I've seen stty being used, which is a real blast from the past.
<larsc>
I actually had a problem with a cypress uart chip and the ACM driver
<larsc>
the device would show up
<larsc>
but never receive anything
<larsc>
maybe the same issue
<larsc>
cypress solved it with an update to their chip
<larsc>
with an firmware update
<paul_boddie>
There are a few things that people seem to have problems with, but they aren't showstoppers: the "not a modem" complaint from the driver, and mtp-probe wanting to look at the device.
<paul_boddie>
Neither of those should cause a problem, and you can fix them by (1) changing the endpoint descriptor, and (2) editing libmtp's udev rules.
<paul_boddie>
People also seem to have problems with modem-manager - it wants anything that declares itself as CDC ACM - but that's not an issue here: the advantage of using Debian instead of Ubuntu. ;-)
<paul_boddie>
Solving the issue with a firmware update is unfortunately my responsibility here.
<larsc>
maybe give cypress a call ;)
<paul_boddie>
They'd be only too happy to help, I'm sure. :-)
dos1 has joined #qi-hardware
rz2k has quit []
viric_ has joined #qi-hardware
viric has quit [Ping timeout: 240 seconds]
viric_ is now known as viric
zhai has quit [Quit: Leaving.]
apelete has quit [Ping timeout: 240 seconds]
arossdotme has joined #qi-hardware
viric has quit [Ping timeout: 240 seconds]
apelete has joined #qi-hardware
viric has joined #qi-hardware
kanzure has quit [Ping timeout: 248 seconds]
arossdotme has quit [Ping timeout: 260 seconds]
arossdotme has joined #qi-hardware
arossdotme1 has joined #qi-hardware
kanzure has joined #qi-hardware
arossdotme has quit [Ping timeout: 260 seconds]
paul_boddie has quit []
kilae has quit [Quit: ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]]
viric has quit [Ping timeout: 240 seconds]
DocScrutinizer05 has quit [Remote host closed the connection]
DocScrutinizer05 has joined #qi-hardware
viric has joined #qi-hardware
<apelete>
Hi there
<apelete>
larsc mth: I've been making some progress, the probe function seems to register the glue layer now -> http://paste.debian.net/53739/
<apelete>
the errors above seem to be related to the way musb-hdrc works with the glue layer to "register/create" the device in usbcore, and I don't know much about that
<apelete>
larsc mth: I would appreciate some help if/when you have time :-)
<mth>
on the jz4770 the "nop" transceiver is used
<mth>
I don't know exactly how that gets selected though
<mth>
CONFIG_NOP_USB_XCEIV=y
<mth>
I think I saw the nop transceiver in your platform configuration, but is the driver itself also enabled in the kernel config?
<apelete>
mth: I copied the nop transceiver from the jz4770 code, but I dont know its purpose to tell the truth
<apelete>
mth: what is the purpose of the "nop" transceiver, and how is used by the musb driver ?
arossdotme has joined #qi-hardware
<mth>
I think it does nothing (nop = no operation), but it is a transceiver, so if the code must have a transceiver then it satisfies that requirement
<mth>
"unable to find transceiver of type USB2 PHY" suggests that a transceiver is mandatory
<apelete>
mth: ok, I see. do you exactly what a USB transceiver is supposed to do in the general case ?
<apelete>
just asking for my general culture :-)
<apelete>
s/exactly/know/
<mth>
I think it's responsible for putting the actual signals and power on the USB connector
<mth>
it controls the part that is closest to the wires
<mth>
for the jz4770 we should probably implement a transceiver; currently there the glue code controls the signal levels and power
<mth>
afaik the jz4740 doesn't have software control over that
<apelete>
so I won't ever need a transceiver in jz4740 other than the nop transceiver ?
<apelete>
<mth> for the jz4770 we should probably implement a transceiver; currently there the glue code controls the signal levels and power
<apelete>
so that's why there are functions like jz_musb_init_regs() and jz_musb_set_vbus() in the jz4770 code I guess...
<mth>
set_vbus is only needed for host mode, which the 4740 doesn't support
<apelete>
in fact I'm wondering how the jz4740 can do without a transceiver (since I'm going to use "nop" transceiver) AND without such functions that handle "actual signals and power on the USB connector"
<mth>
the register flags that the 4770 glue code sets for transceiver-like functionality simply don't exist on the 4740
<mth>
there is a lot less to configure on the 4740
<apelete>
ok. I still don't get the whole picture but I'll see how it turns out in the code anyway, then we'll talk again I guess :-)