Back
[01:00:04] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.6 b7390b8 06linuxcnc 10docs/src/common/System_Requirements.txt docs: fix a typo in the System Requirements document * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=b7390b8
[01:09:08] <seb_kuzminsky> memleak: are you coming to houston?
[01:11:54] <seb_kuzminsky> jepler: should merge commits be exepmt from s-o-b? i dont think there's a flag to 'git merge' to add s-o-b, so you have to merge with --no-commit, or amend the merge commit later
[01:12:17] <KGB-linuxcnc> 03Sebastian Kuzminsky 05master da839b5 06linuxcnc Merge remote-tracking branch 'origin/2.6' * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=da839b5
[01:15:20] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/master/new-deb-configure 8e9f548 06linuxcnc 10debian/configure 10debian/control.in 10debian/rules.in deb: new debian/configure and debian/control * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=8e9f548
[01:15:21] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/master/new-deb-configure fe4d453 06linuxcnc 10debian/configure 10debian/rules.in deb: fix the debian/{control/rules} remaking rules * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=fe4d453
[01:15:21] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/master/new-deb-configure fad0fb1 06linuxcnc 10src/configure.in dont be so picky about wish and tclsh versions * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=fad0fb1
[01:17:13] <seb_kuzminsky> the seb/master/new-deb-configure branch replaces debian/configure with a python script
[01:17:22] <seb_kuzminsky> it's got a simpler internal structure, and all new bugs
[01:17:56] <seb_kuzminsky> it does better than the old debian/configure on wheezy/uspace, but i haven't tested the other bazillion environments really at all
[01:18:30] <seb_kuzminsky> it makes it easy to do things like turn off libgnomeprintui, so it can build debs on jessie and trusty
[07:39:11] <jepler> seb_kuzminsky: a quick glance at merge commits in linux.git and git.git shows no s-o-b on typical merge commits.
[07:39:15] <jepler> e.g.,
https://git.kernel.org/cgit/git/git.git/commit/?id=5d7f49dc79edf476a0b9266ea5f076b723eca6ec
[07:39:21] <jepler> so we could relax this rule
[07:58:53] <jepler> I'd like more opinions first, and of course it means hacking on that script
[07:59:06] <jepler> the counterpoint is: substantive new changes *can* be introduced in merge commits (they just shouldn't be)
[07:59:28] <jepler> since there's no automated way to check whether there actually are substantive changes in a merge commit and not in either parent, it would be better to require the sign off
[08:00:56] <jepler> and a simple alias 'git soba' can sign off the top commit, whether merge commit or not: git config alias.soba "commit --amend -CHEAD -s"
[10:05:16] <seb_kuzminsky> jepler: that all makes sense
[10:06:15] <seb_kuzminsky> i'd prefer it if making merge commits in linuxcnc.git wasn't a weird and unusual thing requiring special commands
[10:07:10] <seb_kuzminsky> i'd also argue that merge commits should *not* introduce substantial changes, and that the developers should properly rebase to accomplish the required changes
[10:34:08] <brianmorel99> I reinstalled off the livecd on my new ASRock J1800 , out of the box with <10,000 Jitter on 25us thread.
[10:35:27] <brianmorel99> USB doesn't work though, luckily I had read others having that issue, so I bought a PS/2 Keyboard & Mouse.
[10:45:04] <CaptHindsight> how not working is the intel USB on these? Do the controllers not even show up in LSPCI?
[10:49:23] <skunkworks> brianmorel99, what are you planning to run? mesa hardware?
[10:51:00] <skunkworks> I am saying that because you could use master and uspace with rt_preempt for servo thread only systems...
[10:51:08] <skunkworks> and then the usb's will probably work.
[10:51:23] <skunkworks> (they did on my gigabit j1800/1900
[10:54:24] <brianmorel99> I don't plan on running a Mesa system yet. I didn't dig to much into it last night, but I had originally installed the standard debian live cd, and USB worked fine. I assume it's a kernel option, perhaps to do with USB 3.0.
[10:55:40] <brianmorel99> Hopefully I have time to dig a little into it tonight, but my system works fine since I have the PS/2. Got to see the mill moving for the first time, it was pretty exciting.
[11:34:34] <seb_kuzminsky> brianmorel99: that's great
[11:36:31] <pcw_home_> other than the USB issue the J1800's/1900s are great, much faster than the Atoms and much better real latency
[12:23:05] <cradek> I wish someone could figure out that usb problem
[12:23:14] <cradek> pcw_home_: are you going to be at the texas thing?
[12:29:40] <pcw_home_> No, Wish I could but a bit too busy
[12:35:46] <CaptHindsight> cradek: it might not be a problem with the newer kernels
[12:38:00] <CaptHindsight> what's the oldest kernel with preempt_rt tested on those Intel boards with the USB problem?
[12:38:08] <pcw_home_> I think its specific to the wheezy RTAI kernel
[12:39:03] <pcw_home_> 3.4.55 (since similar vintage preemt-RT and vanilla kernels are OK)
[12:39:28] <CaptHindsight> ah so maybe just some missing kernel option
[12:40:31] <skunkworks> I think the 10.04 rtai also caused the usb's to not work...
[12:45:03] <CaptHindsight> I guess it's up to whoever puts together the next official kernel
[12:46:55] <skunkworks> I have not had a chance to test memleaks new kernel.
[12:47:12] <CaptHindsight> skunkworks: heh, was just going to ask you about that
[12:49:53] <CaptHindsight> looks like there interest in OpenCV with Linuxcnc
[12:50:09] <CaptHindsight> I should try to get it work work in a tab in Axis
[12:51:34] <CaptHindsight> everything and more that was in camview/camunits is in OpenCV
[12:52:10] <skunkworks> That is actually a question - if I have video processing in a python - how would I pass that to a tab in axis?
[12:52:59] <skunkworks> 'in a python' I sound like I am 80
[12:53:55] <ssi> lolol
[12:56:57] <CaptHindsight> there's a patch for Axis that adds whatever video to a tab
[12:57:59] <CaptHindsight> http://wiki.linuxcnc.org/uploads/axisrc-dynamic-tabs
[13:00:15] <skunkworks> I think that was added to axis at some point..
[13:00:31] <CaptHindsight> and then the INI file just needs a line for: EMBED_TAB_COMMAND = <application> -wid {XID} tv://0
[13:00:53] <CaptHindsight> EMBED_TAB_COMMAND = mplayer -wid {XID} tv://0 is the line to add mplayer
[13:01:14] <CaptHindsight> EMBED_TAB_COMMAND = camview-emc -w {XID} to add camview-emc
[13:01:17] <skunkworks> Because I didnt have to use that patch to add camunits to master..
[13:01:35] <CaptHindsight> good to know
[13:02:32] <CaptHindsight> try adding OpenCV to the EMBED_TAB_COMMAND
[13:03:14] <skunkworks> so - lets say I have mplayer -wid {xid} tv://0 I am assuming //0 is device 0? How would I point that to the video I am processing in the python code?
[13:05:34] <CaptHindsight> I think it works like this EMBED_TAB_COMMAND = <insert video app here> -w {XID}
[13:07:12] <skunkworks> it isn't actually displaying video.. really - it is creating/processing a video stream
[13:07:24] <skunkworks> maybe I am asking the wrong question :)
[13:08:04] <CaptHindsight> all it does is put the video application into the tab in Axis
[13:08:55] <CaptHindsight> camview-emc shows up like this in the tab in axis
[13:09:10] <CaptHindsight> rather than in it's own terminal
[13:10:04] <CaptHindsight> that might not be what you want
[13:10:51] <CaptHindsight> you might want to see the preview or DRO while you have the imaging in a separate window
[13:24:56] <CaptHindsight> forgot to post the pic
http://psha.org.ru/p/axis-camera.png camview-emc in a tab
[13:59:02] <skunkworks> my thought is this.. video camera -> /dev/whatever1-stream -> python opencv processing -> /dev/whatever2 stream -> mplayer. but that must not be a normal process because google comes up with nothing.
[14:15:47] <seb_kuzminsky> CaptHindsight, skunkworks: if there's an obsolete wiki page, would you please remove it? or edit it to say it's obsolete?
[15:08:34] <MrHindsight> seb_kuzminsky: yes, I've been working on updating the pages about working with camview
[15:16:53] <seb_kuzminsky> great, thanks!
[15:28:44] <brianmorel99> seb_kuzminsky: Do you have the source tree for the kernel / rtai you used to build the current RTAI kernel posted somewhere ?
[15:31:25] <seb_kuzminsky> brianmorel99:
https://github.com/SebKuzminsky/rtai/commits/old-3.9-debs
[15:31:48] <seb_kuzminsky> but start here:
https://github.com/SebKuzminsky/linux-rtai-build
[16:00:38] <brianmorel99> The USB worked on the stock Debian 3.2 kernel, but they may have backported a fix. When I get some time I'm going to see if I can isolate the exact error and see where it was fixed.
[16:04:36] <cradek> that would be terrific
[16:07:08] <seb_kuzminsky> i looked for usb patches in the debian kernel, didn't see anything i looked through the debian patches, nothing looked like a usb bugfix
[16:07:33] <seb_kuzminsky> but i might have missed it, so don't let that stop you from looking too
[16:08:30] <seb_kuzminsky> brianmorel99: you can see in the linux-rtai-build repo it checks out
https://github.com/SebKuzminsky/linux-rtai-debian, which is the debian packaging for the kernel
[16:09:24] <seb_kuzminsky> one of my early commits disables most of the debian patches (to make the rtai patches apply easier), that's probably the place to look
[18:40:10] <memleak> seb_kuzminsky: I dont think i will be going to houston sorry :(
[18:41:45] <memleak> if 3.14 still gives anyone USB trouble and 3.8.13 has the same issue i highly doubt 3.16 will fix it.
[18:47:22] <memleak> like i said though, once 3.16 hits ipipe ill port it to RTAI
[18:51:36] <memleak> cant make debs but i can make rtai changes that are worth building a deb for ;)
[19:02:25] <PCW> since a stock 3.4 kernel has no USB issues I dont think its particularly kernel version sensitive
[19:17:51] <jepler> seb's right that it could be a patch that he disabled, if the hardware wasn't originally supported by 3.4 but only by a patch backported from newer linux .. but that's all conjecture on my part
[19:32:20] <seb_kuzminsky> there's no patch in the debian 3.4 kernel that looks at all like a usb fix :-(
[19:33:39] <seb_kuzminsky> nothing in the rtai hal-linux-3.4.55-x86-1 patch touches the usb subsystem
[19:33:52] <seb_kuzminsky> but maybe it monkeys with interrupts or something that usb requires in order to work
[19:46:11] <brianmorel99_> Well, I just booted the stock 3.4 kernel from debian and got the same errors.
[19:47:01] <brianmorel99_> My original install was 64bit, so at the moment, I'm thinking its a 32bit vs. 64bit issue.
[19:48:30] <brianmorel99_> Unfortunately, I used the same USB drive to install the Linuxcnc hybrid.iso, so I don't have the Debian live install cd to test with. I'm fairly certain I remember that being 3.2, but I'll have to wait till tomorrow to check.
[21:10:29] <brianmorel99_> I think I found a patch that would fix it. Looks like it went into 3.12. Tomorrow, I'll install a newer kernel from wheezy backports and give it a try also
