Re: [Bug-xnee] "WARNING: Enough valuators ... still not printing" - what does it mean?

[Henrik Sandklef]

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