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