> 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 > > 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. 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. > 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. > > 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. _______________________________________________ Bug-xnee mailing list Bug-xnee@gnu.org https://lists.gnu.org/mailman/listinfo/bug-xnee