Back
[01:06:09] <jepler> (too bad I didn't know that Hz output was common for mach spindle interfaces when I wrote stepgen ..)
[02:26:15] <jmkasunich> cradek: are you going to post the wood ball vid, or should I?
[02:28:55] <cradek> hmm, this is my chance to not get emails about it
[02:29:01] <jmkasunich> heh
[02:29:30] <jmkasunich> * jmkasunich plays with kino (vid editor)
[02:56:18] <CIA-26> EMC: 03cradek 07TRUNK * 10emc2/src/emc/rs274ngc/gcodemodule.cc: show block delete in the preview
[02:56:21] <CIA-26> EMC: 03cradek 07TRUNK * 10emc2/src/emc/usr_intf/axis/scripts/axis.py: show block delete in the preview
[02:56:28] <CIA-26> EMC: 03cradek 07TRUNK * 10emc2/share/axis/images/axis.ngc: show block delete in the preview
[03:16:21] <CIA-26> EMC: 03cradek 07TRUNK * 10emc2/lib/python/rs274/glcanon.py: fix highlighting for arcs/traverses
[04:17:38] <jmkasunich> rats - youtube barfed on the video
[04:18:15] <jmkasunich> I reformatted it from asf to mpeg4 and rotated it to be upright in the process - mplayer plays it, but youtube can't figure it out
[04:18:18] <jmkasunich> tomorrow.....
[07:17:30] <fenn_> fenn_ is now known as fenn
[12:28:42] <skunkworks_> ug
[12:29:30] <SWPadnos> ook
[12:30:31] <skunkworks_> you're up early :)
[12:30:45] <SWPadnos> yeah. kinda sucks
[12:30:52] <skunkworks_> Heh - are you home?
[12:31:16] <SWPadnos> yep
[12:31:41] <skunkworks_> That is good. ;)
[12:31:56] <SWPadnos> indeed it is
[12:32:12] <SWPadnos> though it would be better if the water heater hadn't died in the storms Sunday night
[12:32:34] <SWPadnos> or mostly died anyway
[12:32:58] <skunkworks_> eww
[12:33:08] <skunkworks_> gas or electric?
[12:33:30] <SWPadnos> gas
[12:33:36] <skunkworks_> must be gas. No real electronics in electric
[12:33:38] <skunkworks_> heh
[12:33:45] <SWPadnos> rented though, so they have to fix it
[12:33:53] <skunkworks_> nice
[12:34:07] <SWPadnos> other than the lack of hot shower thing, yeah, it is nice ;)
[12:34:35] <SWPadnos> I guess I should look at it some more, then call them
[12:35:07] <micges> sorry for early disturbing, but I digged into emc code and saw that HAL pins are all useless copied form motion/traj/emcio to HAL and reverse every servo cycle..
[12:35:40] <micges> could it be that all those memory structures exist in HAL shared memory ?
[12:35:54] <micges> (it saves a lot of CPU cycles)
[12:40:10] <SWPadnos> I don't quite understand your description of the "copies"
[12:40:30] <SWPadnos> all HAL pins are in shared memory, as are signals
[12:40:46] <SWPadnos> there is no copying when pins or signals are accessed
[12:41:24] <SWPadnos> ah - you're talking about how pin values are read and stuffed into other structures (or the reverse)
[12:42:06] <micges> emcmot_hal_data <-> emcmotStatus
[12:42:20] <micges> these are copied in both ways every cycle
[12:42:29] <micges> could be one structure in HAL ?
[12:43:26] <skunkworks_> I was looking at the puma kins source file. I was deciding that I don't understand it. You can set 4 length - but it really doesn't explain what the distances are. (I am sure if I understood the math...) I have been doing searches - might just have to change the lengths and see what happens
[12:43:27] <SWPadnos> Status is something that gets sent via NML to wherever it needs to go. it can't be the same as HAL because NML messages may need to travel over a network
[12:44:17] <skunkworks_> I assume it is the arm and offset for the first 2 joints.. but not sure.
[12:44:19] <micges> oh
[12:44:28] <micges> right
[12:45:13] <SWPadnos> skunkworks_, damfino
[12:59:42] <skunkworks_> :)
[13:21:11] <skunkworks_> On the way home there was a rv that was going the opposite direction shreaded the drivers side tire - crossed the median and came to rest in the passing lane
[14:04:31] <jepler> sizeof(emcmot_status_t) < 2kb. copying 2kb less than once per ms is a tiny tiny amount of work
[14:05:11] <jepler> my 64-bit machine is down; I wonder if it was the storm last night, or if the kernel is still unstable
[14:08:28] <SWPadnos> check dmesg
[14:08:33] <SWPadnos> :)
[14:09:27] <jepler> thanks for that advice
[14:09:42] <SWPadnos> no problem. just let me know if you need more
[14:09:53] <jepler> yes, there's another issue on which I could use some advice.
[14:10:10] <SWPadnos> ok
[14:17:53] <jepler> hi rayh
[14:20:48] <micges> jepler: ok copying is tiny, is there any known bottleneck of emc?
[14:21:13] <jepler> emc performs quite well enough for me, so I haven't searched for them.
[14:24:09] <micges> what about axis ?
[14:24:46] <rayh> Hi guys
[14:24:56] <micges> hi rayh
[14:30:15] <jepler> if I was on a low-resource machine I'd run a different front-end; again, it works fine for me.
[14:32:35] <micges> understand
[15:05:57] <jepler> seb_kuzminsky: let me read your message again, and continue the conversation over here
[15:08:02] <seb_kuzminsky> okey
[15:09:52] <jepler> seb_kuzminsky: hal_5i2x is jmkasunich's work, and I don't know whether he plans to resume it. I don't think it's in a state where it makes sense to package it, but I wouldn't remove it from the source tree either.
[15:10:10] <seb_kuzminsky> i'll be happy to ignore it :-)
[15:10:54] <jepler> seb_kuzminsky: so basically you see mesa-hostmot2 as the future for all mesa cards, but preserve m5i20 for now due to the large installed base?
[15:11:33] <seb_kuzminsky> that's basically it
[15:12:08] <seb_kuzminsky> it prolly makes sense to leave the current m5i20 around and keep supporting it for a longish time
[15:12:17] <jepler> for the few 7i43_hm2 users in 2.2, how extensive arre the hal changes to switch to mesa-hostmot2?
[15:12:25] <jepler> is it mostly a search-and-replace, or is some intelligence required?
[15:12:43] <seb_kuzminsky> the string before the first "." in all the pin, param, & funct names changes
[15:12:47] <seb_kuzminsky> the set of functions changed
[15:12:51] <seb_kuzminsky> that's all i think
[15:13:18] <seb_kuzminsky> oh, also firmware needs to be loaded with bfload before loading the driver now
[15:14:08] <jepler> I think the plan sounds fine
[15:14:43] <seb_kuzminsky> ^_^
[15:14:43] <jepler> how big are all the firmwares put together? I wonder if it's enough to justify having a separate package for them.
[15:14:51] <jepler> uh oh, actual work calls
[15:15:36] <seb_kuzminsky> currently 1.4 MB, for 5i20 and 7i43, final will be maybe 5 MB or so
[15:15:44] <seb_kuzminsky> ok enjoy rl, we'll talk later
[16:20:30] <jepler> cradek: thanks for those bugfixes!
[16:21:05] <cradek> welcome
[16:21:15] <jepler> argh the return of the "touch off dialog doesn't work"
[16:21:37] <jepler> what is it that our unique snowflakes do to cause it?
[16:21:46] <cradek> I think the highlight one is not quite right. it sometimes shows an extra line in cone.ngc when selecting some of the swirly rapids
[16:22:37] <cradek> I haven't yet reproduced the incorrect exceeds-limits warning
[16:23:21] <cradek> I thought it would be easy. but I guess I need to copy the mazak limits and var and use that program
[16:24:28] <cradek> in the preview it's easy to get an incorrect red box around an extents number, but I haven't been able to get the warning.
[16:53:25] <BigJohnT> cradek: I have a ngc file that gives me the exceeds limits warning
[16:53:37] <jepler> hm, according to callgrind, most of the cycles inside task are inside emcIoUpdate (about 69%), compared to 5% for emcMotionUpdate and 8% for NML::write
[16:53:51] <cradek> BigJohnT: I duplicated the mazak setup and I have a test case now, I'm trying to whittle it down.
[16:54:24] <BigJohnT> ok
[17:32:56] <SWPadnos> (jepler, seb_kuzminsky) is the hostmot2 email on the list, or was it private?
[17:33:10] <SWPadnos> I don't see anything that I would immediately link to your earlier conversation
[18:16:00] <jepler> SWPadnos: it was private, I'll bounce it to developers
[18:16:41] <SWPadnos> ok, thanks
[18:17:08] <SWPadnos> I was thinking about the number of bitfiles that were recently checked in - I'm not sure I like the trend :)
[18:21:42] <jepler> yeah that was one of the things on my mind
[19:16:51] <alex_joni> ooooh.. triangle for vismach.py
[19:16:56] <alex_joni> jepler: yay
[19:17:11] <alex_joni> err.. it was jmkasunich :)
[19:18:22] <jepler> yeah thank the right guy
[19:20:25] <seb_kuzminsky> SWPadnos, jepler: the bitfiles have been in TRUNK for a while now, I just installed them in the debian package
[19:20:37] <skunkworks_> Hey alex! :)
[19:20:56] <alex_joni> so who would I have to thank for loading of .stl's or the like ?
[19:21:10] <seb_kuzminsky> i could put them in another package (emc2-mesa-firmware or something) if you think that's better
[19:21:15] <jepler> alex_joni: that remains to be seen
[19:21:20] <jepler> seb_kuzminsky: not at the moment
[19:21:32] <alex_joni> * alex_joni prepares mentally for a long thank-you note to jepler
[19:21:39] <alex_joni> hi skunkworks_
[19:26:09] <jepler> alex_joni: is stl the format that you already made me write a convert for once?
[19:28:31] <alex_joni> no, not stl
[19:29:06] <alex_joni> the format was something properietary, but I extended the converter to write .obj's
[19:29:14] <alex_joni> I think obj's are fairly easy to read..
[19:30:52] <jepler> I see cradek once wrote an ascii stl "parser/converter"
[19:31:04] <alex_joni> yeah, also for me ;)
[19:31:18] <alex_joni> there is a very good triangle-app out there
[19:31:24] <alex_joni> there == sourceforge
[19:31:29] <jepler> triangle-app?
[19:31:39] <alex_joni> it's called meshlab, and reads/writes loads of mesh-formats
[19:32:02] <alex_joni> it also allows some basic interaction (closing holes, colouring,filters, etc)
[19:32:20] <alex_joni> so I wouldn't be too worried about which format we'd support..
[19:40:57] <alex_joni> well.. see you guys later :)
[19:41:10] <jepler> bye
[19:41:10] <alex_joni> (long days at the beach are exhausting :)
[19:41:42] <alex_joni> I'll probably pop in the next evenings
[19:48:37] <SWPadnos> seb_kuzminsky, I just happened to notice the firmware files when you added them to the .deb :)
[19:48:56] <seb_kuzminsky> ;-)
[19:49:06] <SWPadnos> that was one thing that jmkasunich and I were trying to avoid with mesa_5i2x
[19:49:13] <seb_kuzminsky> too bulky? clutter up your downlink?
[19:49:31] <SWPadnos> in a sense, yes - I'm hosting the repository ;)
[19:49:43] <SWPadnos> (or atleast providing the hosting on DH_
[19:49:45] <SWPadnos> _
[19:49:46] <SWPadnos> )
[19:50:27] <seb_kuzminsky> The repo is about 31 MB, of which 1.4 MB is hostmot2 firmware files
[19:50:35] <SWPadnos> it was up around 1.5TB last month (repo + ISO), which is starting to be a noticeable fraction of my bandwidth allotment
[19:50:54] <seb_kuzminsky> when all the anyio boards are supported, there might be 5-10 MB of bitfiles
[19:51:00] <SWPadnos> sure - I don't think it's a problem at the moment, it just occurred to me that it might be at some point
[19:51:06] <seb_kuzminsky> right
[19:51:08] <SWPadnos> that's a lot for a single driver
[19:51:16] <seb_kuzminsky> i agree, it's a lot...
[19:51:16] <SWPadnos> that 99% of users don't use ;)
[19:51:30] <seb_kuzminsky> i could maintain a separate repo of bitfiles somewhere
[19:51:38] <seb_kuzminsky> maybe mesa would host it
[19:52:06] <alex_joni> seb_kuzminsky: it could be in the same repo, but as a different package
[19:52:07] <SWPadnos> mesa_5i2x was supposed to get around that by having tools to stick configuration information into the bitfile, and also program that onformation into a RAM block in the FPGA
[19:52:36] <seb_kuzminsky> SWPadnos: all the possible configs in one bitfile, and block ram to enable/disable what you dont want?
[19:52:49] <SWPadnos> so HM2 would be one bitfile per supported device (7i43, 5i20, 5i22 ...), and the RAM block would tell the driver what to enable/disable
[19:52:53] <SWPadnos> yes
[19:52:55] <SWPadnos> more or less
[19:53:15] <SWPadnos> so the driver knows what pins to export at load time
[19:53:21] <seb_kuzminsky> i dont know for sure, but i get the impression from pcw that he's running out of gates on some boards
[19:53:41] <seb_kuzminsky> ie, the 200K 7i43 might not be able to hold 8 stepgens, 8 encoders, and 8 pwmgens all at the same time
[19:53:44] <SWPadnos> could be - especially on the 200k boards
[19:53:50] <seb_kuzminsky> so different bitfiles for different configs would be needed...
[19:53:52] <seb_kuzminsky> right
[19:54:22] <seb_kuzminsky> alex_joni: you mean a different CVS module in the same repo? or a different debian package built from the same cvs module?
[19:54:34] <SWPadnos> 8 stepgen+8encoder+8PWM should fit into 200k just fine, though I haven't tested that theory :)
[19:54:44] <SWPadnos> same repo, different .deb
[19:54:57] <seb_kuzminsky> if its the same repo it wont help your bandwidth issue
[19:55:12] <SWPadnos> it would if only the people who manually install it get updates to it
[19:55:38] <SWPadnos> consider that the Ubuntu repos have thousands of programs that most of us don't install, and we don't download them every time we update
[19:55:48] <seb_kuzminsky> i see what you mean. yes.
[19:56:23] <seb_kuzminsky> most of your bandwidth is in .debs, not in cvs updates?
[19:56:39] <SWPadnos> cvs isn't on dreamhost, Jeff hosts that :)
[19:56:46] <seb_kuzminsky> ah
[19:57:00] <seb_kuzminsky> gotta go, rl calls
[19:57:06] <CIA-26> EMC: 03jepler 07TRUNK * 10emc2/lib/python/vismach.py: rudimentary support for stl format
[19:57:10] <SWPadnos> the ISO is a lot of it though - something like 1300 downloads last month
[19:57:14] <jepler> once again that whiner gets what he asks for
[19:57:17] <SWPadnos> see you
[19:57:30] <jepler> alex_joni, that is
[20:01:15] <skunkworks_> uh - you can draw objects in cad - export as stl and inport them into vismach?
[20:01:30] <skunkworks_> import
[20:06:19] <SWPadnos> wikkit!
[20:06:24] <SWPadnos> err - nice
[20:06:33] <jepler> hm the lighting doesn't seem quite right
[20:06:53] <jepler> http://emergent.unpy.net/files/sandbox/5axis-magnolia.png uses a model from
http://people.scs.fsu.edu/~burkardt/data/stla/stla.html
[20:07:43] <awallin> the surface normals are probably wrong
[20:08:32] <SWPadnos> yeah, it looks like they could have the wrong sign or something
[20:08:51] <SWPadnos> though that usually ends up making invisibile surfaces, doesn't it?
[20:32:20] <skunkworks_> http://www.electronicsam.com/images/puma/pumaarm.jpg
[20:40:20] <jepler> the normals come from the stl file; I wonder if they use the opposite convention of opengl or something.
[20:40:39] <jepler> oh well, somebody else can clean up after me :-P
[20:43:49] <cradek> or maybe they need normalizing
[20:53:32] <tomp> skunkworks_: 1.5kW on a 110 circuit! yeah, best make that dedicated
[20:54:19] <SWPadnos> they're normalized
[20:54:48] <SWPadnos> at first I thought the file was bad, but it turned out to be stupid CR/LF line endings are neede by STLWorks
[20:54:58] <SWPadnos> +d
[20:55:10] <skunkworks_> tomp: no control :)
[21:33:51] <skunkworks_> stupid question - where is the file that vismach uses for the puma?
[21:37:05] <skunkworks_> bbl
[21:57:24] <jepler> hm the time my hardy/amd64/rtai system crashed could have been correlated with the thunderstorm
[21:58:01] <jepler> I'll say it was that :-P
[22:50:07] <seb_kuzminsky> http://scan.coverity.com/ -- free coverity testing for open source projects
[22:50:17] <SWPadnos> yep, talked to them about that
[22:50:22] <SWPadnos> a couple of years ago
[22:50:25] <seb_kuzminsky> we just started using coverity at my work, it's sweet
[22:50:35] <SWPadnos> cool
[22:50:43] <seb_kuzminsky> did you run it through?
[22:50:50] <seb_kuzminsky> i see emc2 isnt on the scan list right now
[22:50:59] <SWPadnos> no. I don't recall what the issue was, but there was one
[22:51:03] <seb_kuzminsky> hmmm
[22:51:16] <seb_kuzminsky> rtai build environment perhaps?
[22:51:38] <seb_kuzminsky> maybe sim would be easier
[22:52:55] <seb_kuzminsky> it was a technical issue rather than a political problem, i hope?
[22:53:04] <SWPadnos> no, I don't think it's that. I think it had to do with who should be notified of a problem or something of that sort
[22:53:15] <SWPadnos> kind of a crossover ;)
[22:53:20] <SWPadnos> but I don't remember for sure
[22:53:43] <SWPadnos> I don't know how well it can check networked apps either, which EMC is (by virtue of NML)
[22:54:04] <SWPadnos> also, it's got in-kernel parts, so checks for linking behavior are difficult
[22:54:28] <SWPadnos> (though their code grew out of the Stanford Checker, which was used for a long time to check the kernel itself)
[22:54:45] <seb_kuzminsky> anyone mind if i try to get that set up?
[22:54:58] <seb_kuzminsky> the nays have it! :-)
[22:55:02] <SWPadnos> heh
[22:56:00] <jmkasunich> hi seb_kuzminsky
[22:56:09] <seb_kuzminsky> hi jmk
[22:56:19] <jmkasunich> regarding the m5i2x driver subdir.....
[22:56:38] <jmkasunich> I think much but not all of that has been superseded by hostmot2
[22:56:46] <seb_kuzminsky> ok
[22:56:55] <jmkasunich> the part that has not is the stuff that was intended to support people doing their own VHDL
[22:57:08] <jmkasunich> or putting together predefined pieces of vhdl
[22:57:25] <seb_kuzminsky> the hm2 stuff also doesnt do the cool blockram config stuff you did
[22:57:26] <jmkasunich> for example. I have a makefile in there that invokes the xliinx tools
[22:57:37] <jmkasunich> s/did/started/
[22:57:44] <seb_kuzminsky> heh
[22:57:47] <jmkasunich> I never got the user interface bits going
[22:57:58] <SWPadnos> the main advantage over the m5i2x architecture was the ability to use one bitfile with many combinations of enabled/disabled hardware
[22:58:04] <SWPadnos> s/over/of/
[22:58:23] <jmkasunich> to be honest, that was _not_ my primary goal
[22:58:24] <seb_kuzminsky> yes... assuming it can all fit in the fpga, some of the hm2 configs are stretching the 200K parts in particular
[22:59:05] <jmkasunich> I was more interested in being able to mix and match chunks of vhdl - since I planned (and still plan) to do some functions that peter hasn't done, and probably isn't interested in doing
[22:59:50] <seb_kuzminsky> and the hm2 vhdl isnt set up well for that kind of hacking? (i know nothing about vhdl & havent looked at it)
[23:00:09] <jmkasunich> the vhdl is semi-modular
[23:00:25] <jmkasunich> but the driver arch isn't so much
[23:00:34] <jmkasunich> I wanted both vhdl and driver to be modular
[23:02:19] <jmkasunich> I also had these grandiose ideas about letting only moderatedly advanced users reconfig their board
[23:02:46] <jmkasunich> that was really what brought me to a halt
[23:02:49] <seb_kuzminsky> right, by putting firmware config info in the blockram, right?
[23:02:53] <jmkasunich> (well, that and getting divorced)
[23:02:58] <seb_kuzminsky> ouch
[23:03:36] <jmkasunich> swp and I had come up with the idea of 4 classes of users
[23:03:46] <seb_kuzminsky> i remember swp telling me about that
[23:03:46] <jmkasunich> 1) vhdl hacker - writes his own vhdl, and matching driver
[23:04:10] <jmkasunich> 2) vhdl newbid - mixes and matches existing vhdl
[23:04:35] <jmkasunich> 3) advanced user without xilinx tools - turns on and off modules in an existing bitfile
[23:04:51] <jmkasunich> 4) basic user - loads the hal driver and uses whatever pins it gives him
[23:05:41] <seb_kuzminsky> i want to talk about this with you, but i have to go pick up the kids from preschool now, will you be around this evening, say in 3-4 hours?
[23:05:50] <jmkasunich> probably
[23:05:56] <jmkasunich> 3 anyway, that will be 10pm here
[23:06:10] <seb_kuzminsky> ok see you then maybe
[23:06:29] <jmkasunich> ok
[23:08:23] <SWPadnos> sounds like a good time for me too (hopefully)
[23:13:33] <jmkasunich> SWPadnos: do you know anything about video encoding?
[23:14:15] <SWPadnos> precious little, especially if you're looking for mencoder command line options :)
[23:14:33] <jepler> mencoder -endpos 0:59 -oac copy -ovc lavc -lavcopts vbitrate=1800 -vf rotate=1 CLIP6405.ASF -o rotated.avi && mplayer -ao null rotated.avi
[23:14:48] <jepler> this rotates a video but the quality suffers no matter what vbitrate I chose
[23:14:52] <jepler> (get rid of -endpos)
[23:14:58] <jepler> if that's the problem you're stuck on
[23:15:26] <jmkasunich> I got the rotate part down
[23:15:30] <jepler> ah ok
[23:15:38] <jepler> not sure what else you'd like to do
[23:15:44] <jmkasunich> mencoder CLIP6405.ASF -oac mp3lame -ovc lavc -vf rotate=1,harddup -lavcopts vcodec=mpeg4 -ofps 30 -of mpeg -o test3.mpeg
[23:15:53] <jmkasunich> that works, but youtube doesn't like it
[23:16:19] <jmkasunich> last year when I did the festcam vid (assembling a movie from frames) I used vcodec=msmpeg4
[23:16:38] <jmkasunich> which must have worked (unless skunkworks re-encoded it - I didn't do the upload to youtube)
[23:16:55] <jmkasunich> but when I try msmpeg4 now, I get a 2K file that barfs when I try to play it
[23:17:15] <jepler> did you use -of mpeg then? I think it's unusual to put mpeg4 in a .mpeg container, no matter how logical that sounds. ('d consider getting rid of -of and producing a .avi file instead
[23:17:47] <jmkasunich> looks like I did avi back then
[23:17:57] <SWPadnos> hmmm. I wonder if I inadvertently gave jmkasunich a couple of power strips
[23:18:29] <jmkasunich> I haven't unpacked that box yet
[23:18:37] <jmkasunich> I started with 12, no idea how many are there now
[23:19:10] <SWPadnos> I just noticed that I'm missing the one I usually plug the laptop into
[23:19:21] <SWPadnos> so I must have brought it there, but I don't know if I brought it back
[23:19:42] <SWPadnos> (and there's another one I'm pretty sure I brought there, but I don't remember it coming back either)
[23:20:49] <jmkasunich> jepler: I found endpos in the man page, but not "startpos" - is there such a thing?
[23:20:58] <jmkasunich> (I'd like to drop the first couple of seconds)
[23:21:06] <jepler> jmkasunich: -ss I think
[23:21:13] <SWPadnos> ah ha - I found one, and may not have brought the other
[23:23:08] <jmkasunich> -ss, of course, how obvious
[23:23:19] <jmkasunich> how could I miss it on such a short and simple man page
[23:23:44] <jepler> hahaha
[23:23:48] <jmkasunich> (thanks)
[23:23:57] <SWPadnos> -ss == --short-and-simple
[23:26:03] <jmkasunich> uploading, we'll see how it goes
[23:49:27] <jepler> wow kde4 sure managed to piss me off right quick
[23:49:37] <SWPadnos> impossible!
[23:49:56] <jmkasunich> http://www.youtube.com/watch?v=1EYaM4FkASA
[23:50:20] <jepler> hell, even gnome lets you register keyboard shortcuts to launch applications. I guess the dirty kde hippies were too lazy to include it in kde4.
http://bugs.kde.org/show_bug.cgi?id=161010
[23:50:49] <SWPadnos> weird. I'm pretty sure it was there in 3
[23:50:59] <jepler> yes it was
[23:51:08] <jepler> too bad we didn't record that at night with no talking
[23:51:16] <SWPadnos> heh
[23:52:12] <jmkasunich> the talking is no big deal - its not like the machine whining is a great piece of music that is being interrupted
[23:52:44] <jepler> well that's true enough
[23:53:54] <jepler> maybe emc should put in the input device permissions "fix" by default
