[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bug-xnee] "WARNING: Enough valuators ... still not printing" - what
From: |
Henrik Sandklef |
Subject: |
Re: [Bug-xnee] "WARNING: Enough valuators ... still not printing" - what does it mean? |
Date: |
Thu, 14 Jun 2012 23:32:14 +0200 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
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
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: [Bug-xnee] "WARNING: Enough valuators ... still not printing" - what does it mean?,
Henrik Sandklef <=