Back
[01:57:23] <jmkasunich> hi seb
[01:58:36] <seb_kuzminsky> hiya
[01:59:03] <jmkasunich> do you work on gnome? (or is it kde?)
[01:59:25] <seb_kuzminsky> i just switched my primary work machine from gnome to kde, figured i'd try it
[01:59:44] <jmkasunich> I thought you were a dev for one or the other
[02:00:02] <seb_kuzminsky> nope
[02:00:05] <jmkasunich> bummer
[02:00:07] <seb_kuzminsky> must be some other seb
[02:00:17] <jmkasunich> nautilis is annoying me
[02:00:27] <seb_kuzminsky> what's wrong?
[02:00:32] <jmkasunich> trying to understand how it deal with mounting stuff
[02:00:40] <seb_kuzminsky> ugh
[02:00:43] <jmkasunich> I recently added a USB connected hard disk
[02:00:54] <jmkasunich> put it in fstab, and it works great the usual command line way
[02:00:54] <seb_kuzminsky> call me old school, but mounting thru a gui still seems wierd to me ;-)
[02:01:11] <jmkasunich> nautilis has two! entries for it on the side pane, neither of which works
[02:01:25] <jmkasunich> I
[02:01:37] <jmkasunich> I'd be happy to just be able to make those entries go away
[02:01:40] <seb_kuzminsky> heh
[02:01:47] <jmkasunich> but an evening of googling didn't get me far
[02:01:50] <seb_kuzminsky> try the "X" button in the upper right ;-)
[02:02:02] <jmkasunich> heh
[02:02:24] <jmkasunich> there are some things it is nice for - like viewing a whole directory of photos when I get back from shooting
[02:02:39] <seb_kuzminsky> exactly! that's all i use nautilus for too
[02:02:52] <seb_kuzminsky> sorting pics is so much easier with a gui
[02:03:05] <seb_kuzminsky> hey i was looking at emc-on-debian-sarge issues the other day and i came across this:
[02:03:16] <seb_kuzminsky> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Debian_Sarge_Compile_EMC2#Udev_Configuration
[02:03:54] <jmkasunich> what does it mean
[02:03:55] <jmkasunich> ?
[02:04:03] <seb_kuzminsky> looks like a bunch of the "extras" in the debian dir in the CVS tree install stuff in /etc to tweak udev rules
[02:04:17] <seb_kuzminsky> so that makes me think installing one more to help with firmware loading isnt so fugly
[02:04:33] <jmkasunich> for installed, not at all
[02:04:41] <seb_kuzminsky> heh
[02:04:42] <jmkasunich> but RIP has been the stumbling block there
[02:04:59] <seb_kuzminsky> i run rip and it doesnt see so bad to me
[02:05:19] <jmkasunich> RIP is fine
[02:05:32] <jmkasunich> RIP and using the kernel firmware infrastructure is the issue
[02:05:57] <seb_kuzminsky> i agree, but what I mean is even that doesnt seem so bad to me
[02:06:19] <jmkasunich> you just make the symlinks or whatever?
[02:06:53] <seb_kuzminsky> that's one option (ln -s /home/seb/sandbox/src/hal/drivers/mesa-hostmot2/firmware /lib/firmware/hostmot2)
[02:07:17] <seb_kuzminsky> another option is to install an extra udev rule just like in the link above, and then...
[02:07:32] <seb_kuzminsky> loadrt hm2_5i20 firmware=/home/seb/sandbox/.../fw.bit
[02:08:19] <seb_kuzminsky> uh hold on, i have to go sing some lullabies now
[02:18:45] <seb_kuzminsky> i'm baclk
[02:18:49] <seb_kuzminsky> back
[02:19:07] <jmkasunich> didn't miss any excitement
[02:19:47] <jmkasunich> digital cameras are great - I can shoot 100 frames of crap, and then delete it and pretend it never happened
[02:20:02] <seb_kuzminsky> so i'm going to play around a bit and see if there are any hidden gotchas with the request_firmware()/udev solution
[02:20:26] <jmkasunich> I think the only issues are RIP
[02:20:49] <jmkasunich> to date, we've been able to tell people that if they want to get rid of an RIP "install", all they need to do is delete the tree
[02:21:03] <seb_kuzminsky> fixable by those two mechanisms (symlink sandbox into /lib/firmware, or install a new udev rule)
[02:21:22] <jmkasunich> delete the tree, the symlink or rule remains
[02:21:25] <seb_kuzminsky> but other RIP installs modify the system outside the sandbox too
[02:21:31] <jmkasunich> they do?
[02:21:49] <seb_kuzminsky> the link i just pasted says to install udev rules for rip on sarge
[02:22:05] <jmkasunich> hmm
[02:22:11] <jmkasunich> I've never done anything with sarge
[02:22:18] <jmkasunich> I wonder exactly what those rules are for?
[02:22:58] <seb_kuzminsky> sets the permissions of /dev/rtai_shm to 0666, i think
[02:23:06] <seb_kuzminsky> "the permissions of the beast"
[02:23:35] <jmkasunich> I wonder if that is one of those things I did once a long time ago, and now take for granted
[02:23:49] <seb_kuzminsky> it happens
[02:24:14] <jmkasunich> this box has no RT, I compile and run sim only (RIP)
[02:24:23] <seb_kuzminsky> it's really hard to do something as fundamental as emc2, without changing the host system...
[02:24:35] <jmkasunich> my dapper dev box has an RT kernel, and has both installed (I think) and several RIP checkouts
[02:24:41] <seb_kuzminsky> oh, well for sim you're not loading firmwares anyway, so this would never affect you
[02:24:48] <jmkasunich> right
[02:25:07] <jmkasunich> nor would the /dev/rtai_shm thing be needed
[02:25:24] <seb_kuzminsky> the one udev tweak on the sarge page fixes rtai shm perms for all rips, same as the one udev rule i'm thinking about
[02:25:25] <jmkasunich> on the dapper box, the installed version may have already made that /dev change
[02:25:31] <seb_kuzminsky> yep
[02:26:00] <seb_kuzminsky> i think rip isn't quite as inviolate as we sometimes like to think...
[02:26:23] <jmkasunich> you mean as non-invasive?
[02:26:51] <seb_kuzminsky> yes, i think even rip modifies the host system in some configurations (rt but not sim, for example)
[02:27:20] <jmkasunich> perhaps
[02:27:36] <jmkasunich> tho I'd consider that /dev/rtai_shm thing to be part of "rtai", rather than part of "emc"
[02:27:47] <seb_kuzminsky> <shrug>
[02:27:55] <jmkasunich> yeah, semantics
[02:28:19] <jmkasunich> but that is why one rtai install, and one /dev change, will let you run multiple versions of EMC
[02:28:40] <seb_kuzminsky> makes sense
[02:28:42] <jmkasunich> there is no such thing as an rtai run-in-place ;-)
[02:29:03] <seb_kuzminsky> man, i really wish the udev guys had seen the light and accepted the absolute firmware patch i sent them...
[02:29:14] <seb_kuzminsky> i still dont understand why they rejected it
[02:29:39] <jmkasunich> security?
[02:29:53] <jmkasunich> it lets a user hand a file to a piece of kernel code
[02:30:22] <jmkasunich> somewhere there might be a driver that is vulnerable to a finely crafted "firmware" file
[02:30:44] <seb_kuzminsky> they said they're not worried about protecting the kernel from the superuser
[02:30:55] <jmkasunich> actually, I have no idea if a user could pass the path
[02:31:12] <seb_kuzminsky> i say "they" but of course there is no "they", only dozens of disagreeing individuals
[02:31:20] <jmkasunich> heh
[02:31:37] <seb_kuzminsky> passing modparams is not much easier than insmoding drivers, and if the user can do that you lost already
[02:32:53] <seb_kuzminsky> here's the thread:
http://marc.info/?l=linux-hotplug&m=121488506823559&w=2
[02:36:19] <jmkasunich> "the kernel does not make policy discussions"
[02:36:25] <jmkasunich> sorry, decisions
[02:36:32] <jmkasunich> I don't see how that even matters
[02:37:06] <jmkasunich> the policy is in userspace today, and you were only proposing a userspace change (I think, gotta read the first post again)
[02:37:06] <seb_kuzminsky> yeah... i dont know where he got that idea
[02:37:14] <seb_kuzminsky> you're right
[02:37:30] <seb_kuzminsky> i tried to explain that to him a couple of times and he just wasnt listening
[02:37:55] <seb_kuzminsky> or he couldnt explain his reasoning to me
[02:37:59] <seb_kuzminsky> it was very frustrating
[02:37:59] <jmkasunich> he seems to think that "a driver" == "the kernel"
[02:38:24] <seb_kuzminsky> but the driver never makes any choices, it just lets the user make a choice
[02:38:44] <seb_kuzminsky> if the user doesnt say which firmware they want, the driver goes with the default
[02:38:44] <jmkasunich> which is _true_, if the driver is for some "computery" thing (goes back to my distinction between linux drivers, and drivers that are dedicated to an "embedded" application like emc
[02:39:28] <jmkasunich> heh, you got a bit annoyed with him
[02:39:40] <seb_kuzminsky> sigh... yes, my bad
[02:40:12] <jmkasunich> I didn't say it was bad
[02:40:35] <seb_kuzminsky> i think it's bad... it'll make it harder if i ever try to work with marcel in the future
[02:41:00] <jmkasunich> earlier you said "there is no they, only disagreeing individuals"
[02:41:18] <jmkasunich> unless I missed a branch of the thread, there was only _one_ disagreeing individual
[02:41:18] <seb_kuzminsky> yeah that was kind of a liberating insight
[02:41:37] <seb_kuzminsky> yeah only marcel replied in that thread
[02:42:52] <seb_kuzminsky> since no one else picked up the patch or replied, it gives the impression they agree with him
[02:43:16] <jmkasunich> either that, or they don't care one way or the other, and don't feel like arguing with him
[02:44:28] <seb_kuzminsky> one of the good things about open source, of course, is you dont need consensus
[02:44:37] <seb_kuzminsky> you can do what you think is right
[02:44:55] <jmkasunich> at least on your own system
[02:45:23] <jmkasunich> I'm reading about udev rules right now
[02:45:37] <seb_kuzminsky> udev's good stuff
[02:45:46] <jmkasunich> I gather (haven't got that far) that you can write a rule that triggers on a specific driver only?
[02:46:38] <seb_kuzminsky> yes
[02:47:07] <jmkasunich> are things like /dev/disk/by-label/ products of udev?
[02:47:19] <seb_kuzminsky> yes
[02:47:24] <jmkasunich> that is quite nice
[02:47:28] <seb_kuzminsky> everything in /dev is by udev
[02:48:01] <jmkasunich> yeah, but the "by-label" stuff never existed before (that I recall), while /dev/sdf1 did
[02:48:32] <seb_kuzminsky> yeah by-label is new, but even the stuff that existed before is handled by udev now, just in a backward compatible way
[02:48:38] <jmkasunich> I labeled my USB connected backup drive, and my fstab entry uses the label - result is I can plug it into any usb port and it will mount correctly
[02:48:44] <jmkasunich> understood
[02:49:03] <seb_kuzminsky> it's the shiznit
[02:49:15] <seb_kuzminsky> i think we're pushing the envelope of firmware loading a bit here
[02:49:38] <seb_kuzminsky> in the current view, firmware is something that doesnt change much, and you certainly dont have a choice which firmware to use
[02:49:41] <jmkasunich> we're doing "application specific" firmware loading, rather than system level loading
[02:49:49] <seb_kuzminsky> right, exactly
[02:50:39] <seb_kuzminsky> jepler once mentioned he might want the hostmot2 firmwares all out in their own package, not part of emc2
[02:50:43] <seb_kuzminsky> which might actually make this easier
[02:50:55] <jmkasunich> that package could install the rule?
[02:51:02] <seb_kuzminsky> i imagine the firmware will be the same across all emc2 branches
[02:51:15] <jmkasunich> I dunno
[02:51:32] <seb_kuzminsky> the firmware package wouldnt need a special rule, if it was installed as a .deb with the firmwares in /lib/firmware
[02:51:36] <jmkasunich> new firmwares might only have matching drivers in newer emcs
[02:52:17] <seb_kuzminsky> the hostmot2 driver will happily skip over parts of the firmware it doesnt understand, and use the rest
[02:52:40] <jmkasunich> I see - but that still leaves you with a lag between new firmware being created, and a package containing it being released
[02:52:44] <seb_kuzminsky> so there might be a handful of firmwares that work on both 2.2 and trunk, and a few that need trunk for full support
[02:52:49] <jmkasunich> today, cvs users can get new stuff within minutes
[02:52:55] <seb_kuzminsky> sure, lag, same as now
[02:53:02] <jmkasunich> not same as now
[02:53:24] <jmkasunich> if you commit something now, my RIP "install" can be running it in 10 minutes
[02:53:33] <seb_kuzminsky> i see, right
[02:53:45] <seb_kuzminsky> the firmware package would be easy to make, it doesnt even need to compile anything
[02:54:26] <seb_kuzminsky> i donno
[02:54:48] <jmkasunich> I don't have an opinion on that I guess - but the rules or other tricks needed to run with firmware in a sandbox still need to be documented somewhere
[02:55:05] <jmkasunich> if only for people who download the xilinx tools and do their own firmwards
[02:55:20] <seb_kuzminsky> agreed
[02:55:40] <seb_kuzminsky> absolute firmware paths, it's the right answer... :-(
[02:55:57] <jmkasunich> that is a patch to firmware.sh, right?
[02:56:15] <seb_kuzminsky> yes
[02:56:49] <seb_kuzminsky> or, since upstream udev didnt accept it, a custom rule and a custom hostmot2-firmware.sh helper script
[02:57:17] <jmkasunich> why "hostmot2-firmware.sh", I'd call it abs-firmware.sh
[02:57:29] <seb_kuzminsky> good idea
[02:57:57] <seb_kuzminsky> the udev rule would mention the hostmot2 driver by name, and invoke abs-path-firmware.sh for any requests from hostmot2
[02:58:07] <jmkasunich> the rule doesn't have to be very specific either, if the script is basically your patch
[02:58:48] <seb_kuzminsky> if the rule doesnt limit itself to the hostmot2 driver's requests, then all firmware loading would go through abs-firmware.sh
[02:58:57] <seb_kuzminsky> not sure i can handle that much responsibility ;-)
[02:59:31] <jmkasunich> heh, you were willing to when you proposed the patch
[02:59:35] <jmkasunich> ;-)
[02:59:39] <seb_kuzminsky> true
[02:59:44] <jmkasunich> but I understand completely
[03:00:01] <seb_kuzminsky> there's something about the extra eyeballs you get when upstream takes the patch
[03:00:02] <jmkasunich> it is more prudent to avoid mucking with stuff that doesn't need mucked with
[03:00:13] <seb_kuzminsky> i'd hate to break stuff and have it blamed on emc2/hostmot2
[03:00:55] <seb_kuzminsky> anyway... i'm going to look into that, see if there are any gotchas i missed
[03:01:08] <jmkasunich> still reading about rules
[03:01:16] <jmkasunich> you're planning on using the "DRIVER" key?
[03:01:18] <seb_kuzminsky> it may all be for naught and i'll be linking upci and libpci together ...
[03:01:24] <seb_kuzminsky> DRIVER="hostmot2"
[03:01:47] <seb_kuzminsky> or DRIVER="anyio_manager" or whatever
[03:03:30] <seb_kuzminsky> oops, DRIVER=="hostmot2"
[03:03:38] <jmkasunich> I wonder if ATTR matching could be used
[03:04:06] <jmkasunich> ATTR=="mesa5i20" or ATTR=="mesa"
[03:04:28] <jmkasunich> that way hostmot2 or some other driver (matching some other fw) could export the same ATTR value
[03:04:33] <seb_kuzminsky> ATTR=="wants-absolute-path"
[03:04:55] <seb_kuzminsky> ATTR{wants_abs_path}=="yes"
[03:05:09] <jmkasunich> yeah
[03:05:43] <jmkasunich> wants_abs_fw_path
[03:09:30] <jmkasunich2_> logger_dev: bookmark
[03:09:30] <jmkasunich2_> Just this once .. here's the log:
http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2008-07-12.txt
[03:35:44] <jmkasunich> so, should I call it "clock" or "timer"?
[03:36:01] <jmkasunich> to me clock means that it displays actual time, not elapsed time
[03:37:20] <cradek> I agree clock is the wrong word
[03:37:54] <cradek> chronograph or (less precise but shorter) timer are the only two ideas I have
[03:38:04] <jmkasunich> timer is what I'm using
[03:38:20] <jmkasunich> trying to decide if it should have two hal pins
[03:38:25] <jmkasunich> reset and run
[03:38:39] <jmkasunich> that way you can pause it without resetting it
[03:38:52] <cradek> could you tie reset and run together to get the behavior I want?
[03:39:04] <jmkasunich> reset would have to be active low
[03:39:31] <jmkasunich> I was thinking the same thing tho - don't want the user to have to do wierd hal stuff
[03:39:32] <cradek> no I want rising edge: reset and then count up. low: stop counting
[03:39:51] <jmkasunich> oh, I suppose reset could be rising edge sensitive
[03:40:01] <jmkasunich> and count would be level sensitive
[03:40:22] <cradek> if that doesn't seem too obscure it would be simple to hook up
[03:40:49] <jmkasunich> its not too obscure as long as its documented
[03:41:11] <jmkasunich> "reset is rising edge sensitive - this allows it to be connected directy to count to achieve....."
[03:41:41] <cradek> a timer would have 'run' instead of 'count'
[03:41:52] <jmkasunich> is the pyvcp_widgets.py in lib the "source"?
[03:41:56] <jmkasunich> right about run
[03:42:05] <cradek> sorry I have no idea how that stuff works.
[03:42:26] <cradek> seems like it would be in src/emc/usr_intf somewhere
[03:42:29] <jmkasunich> I couldn't find anything that looked like it defines the widgets in the src section of the tree
[03:43:03] <jmkasunich> there is a pyvcp.py in src/hal/user_comps, but it is short
[03:43:22] <jmkasunich> the widget code seems to be in lib/python/pyvcp_widgets.py
[03:47:20] <jmkasunich> it would help if I knew a tiny bit more python
[04:19:40] <jmkasunich> got a widget that counts
[04:19:45] <jmkasunich> but it doesn't count seconds yet
[04:20:28] <jmkasunich> hmm, this is harder than I thought, if I want to have "run" work right - can't just store the start time
[04:39:30] <alex_joni> hi all
[04:39:30] <jmkasunich> uh-oh
[04:39:30] <jmkasunich> either I'm very late or you're very early
[04:39:30] <alex_joni> really early :P
[04:39:30] <alex_joni> 7:30 on a sunday
[04:39:31] <alex_joni> err
[04:39:34] <alex_joni> saturday
[04:48:17] <jmkasunich> timer widget seems to work
[04:52:06] <seb_kuzminsky> goodnight folks
[04:52:12] <jmkasunich> goodnight seb
[04:52:20] <jmkasunich> too slow
[04:52:25] <alex_joni> whee.. lots to read back again :)
[04:52:31] <alex_joni> <- even slower
[04:59:39] <alex_joni> see you guys.. nice day in the mountains today (I hope..)
[05:00:04] <jmkasunich> enjoy
[05:05:06] <CIA-32> EMC: 03jmkasunich 07TRUNK * 10emc2/lib/python/pyvcp_widgets.py: added a timer widget to pyvcp - can be used to see how long a g-code program took to run
[21:02:10] <CIA-32> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/config/ini_homing.lyx: Added HOME_FINAL_VEL