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

[Henrik Sandklef]

Have been travelling for some days so I never found some proper time
to look into your email until now.

On Fri, Apr 20, 2012 at 06:05:05PM +0000, L. Rahyen wrote:
> > No, not at all. I am, myself, so used to use the stop key to stop recodring 
> > (e.g: "-sk q" makes Xnee stop recording when you press 'q') so this is well 
> > ..... forgotten, neglected... But it will be fixed.
>       Thanks.
> 
> > > % ./cnee --record --events-to-record 6 --keyboard
> > > ...
> > > 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
> > > 7,3,0,0,0,50,0,504416384,20,TypeMatrix.com USB Keyboard
> > > 0,3,0,0,0,50,0,504416384
> > > 6,3,0,0,0,50,0,504416384,3,Virtual core keyboard
> > > 
> > >   To me this looks like unexpected behavior. "0,2,0,0,0,50,0,504416288" 
> > > and "0,3,0,0,0,50,0,504416384" contain only duplicate information, and 
> > > virtual core events seem to always repeat real device events, so 
> > > basically they contain duplicate information too. I naturally expect to 
> > > see this output instead:
> > > 
> > > % ./cnee --record --events-to-record 2 --keyboard
> > > ...
> > > 7,2,0,0,0,50,0,504416288,20,TypeMatrix.com USB Keyboard
> > > 7,3,0,0,0,50,0,504416384,20,TypeMatrix.com USB Keyboard
> > > 
> > >   When I ask for 6 keyboard events to be recorded, I expect 6 events to 
> > > be recorded, not 2. If there is valid reason for current behavior, I 
> > > would appreciate if you explain it, perhaps I'm missing something here? 
> > > This is true for mouse too. Also, this unnecessary duplication makes log 
> > > files about 3 times larger.
> > The recording of all the "duplicate" events are done so that Xnee 
> > afterwards can replay the session:
> >  * as XI master device
> >  * as XI slave device
> >  * as good old fashioned X device
> > I guess we could through in an option to only record XI slave events, or 
> > X11 core events. But I think the sizes of the log files is not really a 
> > major problem so I'd rather not have a new option.
>       I think you misunderstood me. What I'm saying is that there is no point 
> in recording duplicate information. So there is no need for new option. As 
> you see in the example above, I even see no point in saving device id or name 
> for virtual core devices. Their ids should not matter when replaying because 
> they can be easily discovered at runtime; by the way, cnee already discovers 
> them at runtime: virtual core device name or id seems to be never used, 

Ah, ok.

You're probably right. I vaguely remember adding this information to
remove it (from the source code) afterwards. Will do some thinking
before removing it though. Perhaps one would like to do some odd
remapping of XI devices when replaying in the future.

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.

> so basically virtual core events contain as much information as X events as 
> far as cnee is concerned - in fact I can simply truncate ",3,Virtual core 
> keyboard" part and cnee will replay the log perfectly with 
> --force-core-replay option.

With this option (--force-core-replay) Xnee totally discards the recorded 
XInput events.

> And if you ignore additional XI information (",20,TypeMatrix.com USB 
> Keyboard" in the example above) and replace "7," with "0,", you get an event 
> from "old fashioned X device". So if only XI device events are recorded, it 
> is technically possible to replay them as XI virtual core events or X core 
> events if necessary. And it is technically possible to replay X device events 
> as virtual core events - they contain exactly the same information from cnee' 
> point of view anyway (first field is the only difference in current format).

You're right again. As far as I remember the XI motion events recorded
differed a bit compared to the "core" motion events in earlier
releases (of XI I assume).

>       You are right, this is not a major problem. 

What I meant was that I wanted to push this problem a bit ahead and get 3.13 
released. After that (basically now) it's aout time to fix this bug. No bugs 
are too small too fix.

> But other problems I have reported are not major either because workarounds 
> using simple shell tools can be made to filter out "enough valuators" 
> warnings and empty mouse motion events, it is possible to write wrapper 
> script to count events correctly, and it certainly possible to filter out 
> effectively duplicate lines (and it is possible to replay log file without 
> duplicate lines). But workaround is not a fix, and writing shell scripts with 
> hacks to get usable/clean/compact replayable log does not feel right. I think 
> that when everything just works as expected without any workarounds, it is 
> much better.

Agree 100%

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

Asking you to prove it may sound a bit tough, but please don't take it
as me not trusting you, I am really interested.

> Also, this duplication needs to be filtered out if the log needs to be 
> processed by a script. Don't get me wrong, I like cnee output because its 
> simple text format makes it easy to write a script(s) to process it any way I 
> like, and the fact that each line contains all information about each event 
> also can be useful. But obvious data duplication like this (of whole lines) 
> is not a good thing, it does not make processing simpler (by xnee itself or 
> external script), it just wastes memory for no reason.

Point taken. And (again) I agree with you.

>       However, size and massive data duplication are not the only problems. 
> If original XI device is missing or its ID has changed, cnee will crash when 
> trying to replay (and if device with same ID but different name will appear 
> it couldn't tell the difference).

Hmm, this is yet another bug :(  (but thanks for reporting it!!!)

>       I think it would be much better if only events for XI device(s) will be 
> recorded (like in my example above) when XI is supported, 

ACK

> and if device with recorded ID and name does not exist anymore when replay 
> started, try to find device with exactly the same name, and if this fails too 
> or if --force-core-replay option was given, recorded events should be 
> replayed as virtual core events instead, 

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?

> or as X events if no XI support detected or --disable-xinput-events was 
> given; if log contains only X events because was recorded with 
> --disable-xinput-events (useful to get compact portable log) or without XI 
> support at the moment of the recording, replay them as X events by default, 
> or as virtual core events if --force-core-replay option was given. This way 
> there will be only two types of log: X core events log and XI device event 
> log, and both will be interchangeable and portable, only difference between 
> the two will be additional two field for XI device ID and name; no hackish 
> wrapper scripts will be necessary to get portable and compact XI event log, 
> and no crashes will happen if original XI device(s) are missing or their ID 
> has changed. Correct me if I'm wrong, but first field seems to be unnecessary 
> if it only has 3 possible values, all of which can be autodetected by the 
> logic described above. This is of course not only possible solution, but it 
> looks like a good one from my point of view.

Thanks a lot for all your work :)

I agree (with a tiny change (see "Ok?" question abovce)).

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

>       I really appreciate the work you already have done. Xnee allowed me to 
> relatively easily write a script to record and replay interactive macros 
> (interactive in the sense that they can be controlled interactively when they 
> are running, unlike simple replay, which cannot be controlled, only stopped), 
> allowed me to create some non-interactive automation scripts,

         :)

> and even optimize layout on my keyboard by collecting statistics of what I 
> type. I'm also using it as sort of backup tool in case I lose something I 
> have typed (I use hotkey to pause event recording before typing passwords so 
> there is no security risk) - I wrote a script that converts its log to 
> readable format and therefore I can easily "restore" something I have typed 
> in the past but lost for whatever reason (including browser crash, especially 
> in case when I had typed a lot of unsaved text in it). So, as you can see, 
> xnee is very important tool for me which I use every day in my scripts and 
> cron jobs. Just thought I share my reasons to use xnee in the hope it may be 
> interesting how many things can be accomplished with xnee.

Makes me happy to hear.

>       I plan to clean up and improve usability of all my xnee-related scripts 
> and make them a part of one project (I do not write its name because I didn't 
> register a domain for it yet), add few additional features and GUI front-end, 
> and then release it under GPL. Some features I plan to add include 
> mouse/touchpad sensitivity calibration and optional mouse/keyboard statistics 
> (this feature may remind Mousotron, but more advanced and usable in Linux), 
> in both these cases I will need to record XI events, so I can't use 
> --disable-xinput-events, and I need to keep logs replayable and portable, 
> otherwise some things will not work. This is why I encountered all mentioned 
> problems when recording or replaying XI events.     Xnee helped me a lot, 
> without it all of this wouldn't be so easy to implement, so I felt that it is 
> my duty to at least report all problems/bugs I have found, because if I 
> silently create lots of hackish workarounds in my project, no bugs in xnee is 
> going to be fixed unless somebody reports them or you encounter them 
> yourself. You already fixed some of the bugs I have reported, and I'm very 
> grateful for that.


:) 

If you'd rather commit patches and send code (keeping you as author) to the 
Xnee project you're more than welcome. I do, however, want one copyright 
holder, as most/all GNU projects.


Many thanks, henrik