Really busy with grading students on some courses. In case you need some stats before you go to sleep:
http://sandklef.wordpress.com/2012/05/31/os-and-ide-stats-from-2012-embedded-project-at-chalmers-gothenburg-university/ On Fri, May 04, 2012 at 11:47:51AM +0000, L. Rahyen wrote: > > Have been travelling for some days so I never found some proper time > > to look into your email until now. > It's OK. I wasn't around my computer for few days again, so couldn't > answer quickly either. > > > I don't like recording the device name (the enitire string) on all > > lines. This can be optimised away. But I would propose to keep it as > > is. > Device name is useful information, so please keep it. I plan to use it > in my project for collecting per device statistics. And having it in all > lines is not as useless as you think. Its good for filtering by device name, > convenient for manual or automatic editing (for example, it is possible to > remove any portion from a log without losing device names in remaining > events). > It's better idea to optimize away virtual core device names ("Virtual > core keyboard", "Virtual core pointer") along with all the duplicate > information. After such an optimization instead of three lines per XI event: > > 7,2,0,0,0,50,0,504416288,20,TypeMatrix.com USB Keyboard > 0,2,0,0,0,50,0,504416288 > 6,2,0,0,0,50,0,504416288,3,Virtual core keyboard > > ...we will have single line per XI event (with device name and id): > > 7,2,0,0,0,50,0,504416288,20,TypeMatrix.com USB Keyboard > > ...or (in case XI is not supported or --disable-xinput-events was > given): > > 0,2,0,0,0,50,0,504416288 I think this is the ccorrect way of doing this. Will look into it. Thanks! This fix can be tracked here: https://savannah.gnu.org/bugs/index.php?36662 > > > Log size is important, because if used as is, it will waste memory: > > > both RAM (will use almost 3 times more space in RAM buffer than > > > necessary) and disk space. This is especially bad when recording mouse > > > events and RAM buffer set to be rarely written to disk (for maximum > > > performance when enough RAM is available) because this problem may force > > > it to be written more frequently than usually and therefore decrease > > > overall performance. > > Have you noticed a decreased preformance loss? > When recording XI mouse events, and mouse is used actively, if there is > almost no free memory, very little space for disk cache, and write buffer is > set to be written to disk rarely for optimal performance, it is possible to > measure very minor decrease in average performance in read disk operations > (because slightly larger write buffer means slightly smaller disk cache). > Obviously, this will not be noticeable from user' point of view. With default > Linux settings (which are slower but safer for unstable or unprotected by UPS > systems) difference is so small that it isn't measurable. So, it isn't too > bad after all when recording. > However, when processing large logs (with 3 lines per event) with a > script, it takes >2 times more time than to process the same logs with 1 line > per event (also, processing unnecessary larger logs pollutes the disk cache > more). Reducing log size would help to minimize the problem. Of course, this > is not a typical usage of xnee logs, and not a major problem. ok ok ok ok, I'll remove the two lines in the recorded file ;) > And since we are talking about optimizing log size, is there a reason > why "binary printout will not be implemented" (quote from xnee/src/parse.c)? > I ask because I could implement it when I have some free time - xnee binary > printout would be useful in my project. Oh, I really like the plain text version. But hey, why not elaborate on an extra and optional binary printout :) As you *may* have noticed I don't have the time I wish I had on this. I need to focus on my paid work. > > I'd rather have Xnee exit if no mapping could be done (between XI devices), > > and suggest use to use the --force-core-replay switch. > > Ok? > OK. But it would be nice if it will exit with some unique exit code > specific to this case. Keep track of it here: https://savannah.gnu.org/bugs/index.php?36663 > > > All of above is just my opinion, and if you do not have free time to > > > fix this particular problem, I understand. I have very little free time > > > myself (this is why I report these problems instead of reading XI specs > > > and the xnee code and fixing them myself and sending patches). Everybody > > > have different priorities and points of view. But if you decide to look > > > into this problem at any point in the future, let me know if you need > > > more information. > > I have very little time, but given your input I really fell like doing it. > Thank you for deciding to look into all the problems/bugs I have > reported. > thanks for yout time _______________________________________________ Bug-xnee mailing list [email protected] https://lists.gnu.org/mailman/listinfo/bug-xnee
