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

[L. Rahyen]

> 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.