Mouse movement commands getting buffered? about gimx HOT 36 CLOSED

From [email protected] on May 07, 2010 13:41:46

Summary: [v2] Mouse movement commands getting buffered?

from gimx.

From [email protected] on May 07, 2010 14:31:42

I see only one explanation to this behavior. There must be a high rate of events
(more than 32 in 10ms) that are get by the SDL library.

I propose you the following actions:

1. increase the event buffer: try to increase EVENT_BUFFER_SIZE to a high value (512
   for ex)
2. uncomment line 208, that will print the number of events that are caught into 10ms

If 1. solves the problem or makes the buffering effect lower, we should find out what
is the source of these events.

from gimx.

From [email protected] on May 07, 2010 14:48:28

I changed the EVENT_BUFFER_SIZE in emuclient.c to 512, recompiled, but did not notice a
difference.

from gimx.

From [email protected] on May 08, 2010 03:26:35

Labels: -Priority-Medium Priority-Critical

from gimx.

From [email protected] on May 08, 2010 03:30:52

Please uncomment line 208, change debug to 1 and get emu and emuclient traces as in issue 4 .

from gimx.

From [email protected] on May 08, 2010 05:33:06

This will not solve the issue, but dead zone has to be set to 8 for Battlefield: Bad
Company 2.

from gimx.

From [email protected] on May 08, 2010 05:39:45

Status: Accepted
Owner: [email protected]

from gimx.

From [email protected] on May 10, 2010 00:20:57

I will get these settings changed and report back as soon as possible.

from gimx.

From [email protected] on May 10, 2010 02:02:29

• If you have enough time, could you please test your mouse polling rate?

In a terminal:

wget http://www.fileden.com/files/2006/7/4/107702/evhz.c gcc -o evhz evhz.c
sudo ./evhz

Thanks in advance.

from gimx.

From [email protected] on May 10, 2010 09:11:33

Here are my results you asked for.

Changed "static int debug" to 1 in emuclient.c
Changed the "DEAD_ZONE" variable to 8
uncommented line 208 in emuclient.c

I also ran the mouse polling rate test. I'll include what was outputted by that
command.

Attachment: evhz.log results2.tar.gz

from gimx.

From [email protected] on May 10, 2010 09:36:16

Thanks.

Did you got emu and emuclient traces too? (the output of each process redirected in a
file)

from gimx.

From [email protected] on May 10, 2010 09:50:14

These are not the complete traces, just the buffer I had. Let me know if you need the
complete traces.

Attachment: emu.trace emuclient.trace

from gimx.

From [email protected] on May 10, 2010 12:12:04

I don't see anything suspect in the traces :(

Is it possible to tell if the buffering effect is on the emuclient side?

Launch emu and emuclient into two windows.

How do the traces behave in the emuclient terminal? Does it react quickly or not?
Same question in the emu terminal?

from gimx.

From [email protected] on May 10, 2010 12:19:12

On both the server and client side the inputs look ok. Data stops scrolling the
instant I stop moving the mouse. But on the Playstation, it acts as though I am still
moving the mouse around.

from gimx.

From [email protected] on May 10, 2010 12:35:28

Try to increase REFRESH_PERIOD up to 20ms in emuclient.c, recompile and test again.

If it works, try to decrease it down to the lower value it can work.

I have an old PS3, but you have a slim PS3... If the PS3 slim is less responsive than
the old one, it will be a shame!

from gimx.

From [email protected] on May 10, 2010 16:26:52

No result with the change to 20ms. I have a fat PS3 that I can test on at a different
location. I could test it there, but no real time frame on when that would be.
Everything is looking very hopeful so far!

from gimx.

From [email protected] on May 11, 2010 02:00:30

I hope it doesn't depend on the PS3 version.

The bluetooth stack/connection may cause the buffering (it's wireless, so there can
be errors/retransmits).

What is the distance between your PC and your PS3?
What is the exact model of the dongle you are using?
Can you try another dongle?

Further tests:
(In a terminal)
hciconfig -a hci0
-> reproduce the issue
hciconfig -a hci0

Report the output these commands.

Thanks for all the tests done until now!

from gimx.

From [email protected] on May 11, 2010 07:07:48

I looked closer at the emu traces, and I detected a problem. It may happen that
several commands are sent to the PS3 in a few ms (there should not be more than 1
command in 10ms).

Is it possible to tell if the buffering effect is always present or is transitional?

from gimx.

From [email protected] on May 11, 2010 08:08:33

One more test to do:

Set debug to 2 in emu.c, recompile and reproduce the problem, and report the traces
of the emu process.

from gimx.

From [email protected] on May 11, 2010 09:50:30

Forget last 3 comments, I think I have found the problem.

Checkout the emu.c again, recompile, and try to play.

I think the buffering is located between the emuclient and the emu.

It seems there is some transitional latency in the inter-process communication.

I did a first patch that makes only the last command available to be applied.

But we should find what generates that latency.

If it still doesn't work, then read last 3 comments.

from gimx.

From [email protected] on May 11, 2010 10:21:19

Thanks, I will test as soon as possible.

from gimx.

From [email protected] on May 11, 2010 12:10:39

Hi,

This has been a long-standing problem with emu.
Check the logs on the original svn tree, particularly r3539 :

"Sending reports every 10ms is too fast, they start to lag.
Sending reports every time we get a OUTPUT report from the PS3 is still too fast.
Currently I'm just using 20ms as a fixed value, that seems to work
pretty well. Need to do more testing with a sixaxis and figure out
how this timing should really work..."

I never resolved it.

from gimx.

From [email protected] on May 11, 2010 12:29:49

Hi,

It actually works great on my side!

In the traces provided by dmcreynolds, everything seems ok on the emuclient side:
there is at least 10ms between commands send to the emu.

But on the emu side, several packets may be retrieved from the socket in a single
recv() call.

As the send() call in the emu is blocking, an explanation could be that it takes too
much time (>10ms) to return... making the next packets be processed in a single
recv() call.

I really don't know why it run smoothly on my side...

from gimx.

From [email protected] on May 11, 2010 12:43:24

I added debug traces (set debug to 2) in emu to measure the time the blocking send()
is tacking.

I have times lower than 200µs.

from gimx.

From [email protected] on May 12, 2010 01:38:07

I added the debug traces at the wrong place... I'll correct that asap.

from gimx.

From [email protected] on May 12, 2010 09:49:49

Debug traces added at the good place.

from gimx.

From [email protected] on May 12, 2010 16:15:00

Had time to test the new revision with debug set to 2. Here was the output, looks
like everything was around 90.

Attachment: emutrace.txt

from gimx.

From [email protected] on May 12, 2010 16:59:06

Thanks.

Please perform actions described in Comment 22.

from gimx.

From [email protected] on May 12, 2010 17:15:54

What is the distance between your PC and your PS3?
15 ft.

What is the exact model of the dongle you are using?
Manufacturer: Cambridge Silicon Radio (10)

Can you try another dongle?
No.

Attachment: hciconfig.output

from gimx.

From [email protected] on May 16, 2010 06:42:26

I have no idea about what's going wrong.

I'm going to sniff the bluetooth connection between a real sixaxis and a PS3 so a to
try to figure out how the emulator should exactly behave.

from gimx.

From [email protected] on May 20, 2010 02:56:30

Please do the following new actions:

1. get the latest source code and compile
2. in a terminal: sudo hcidump -l 4096 -w capture.dump
3. launch both emu and emuclient with debug traces = 2 redirected into files
   emu.trace and emuclient.trace
4. reproduce the problem: move the mouse and get some lag over about half a minute
5. Stop the capture (ctrl+c).
6. Attach capture.dump, emu.trace and emuclient.trace to this issue.

Thanks in advance

from gimx.

From [email protected] on May 20, 2010 08:08:39

I will get to this as soon as I can. Thanks for keeping up on this issue!

from gimx.

From [email protected] on August 27, 2010 04:30:18

A user told me on my blog that he had the same problem. He tried with another PC but with the same dongle, and the problem occurred too. Then he bought another dongle, and the problem vanished...

To anyone running into this problem, I suggest to try another bluetooth dongle.

See http://diy-machine.blogspot.com/2010/05/please-give-me-feedback.html user=Almeida

from gimx.

From [email protected] on August 27, 2010 04:36:36

dmcreynolds, could you please give me the output of "sudo hciconfig hci0 revision" for your dongle?

I want to know if there is something common between your dongle and Almeida's dongle.

from gimx.

From [email protected] on January 27, 2011 08:25:18

Summary: Mouse movement commands getting buffered?

from gimx.

From [email protected] on March 04, 2011 01:18:20

No more user input => closed.

In my opinion, there is a compatibility problem with some bluecore02 dongles.
It could be a dongle or a bt stack (bluez) problem, and in this last case it may also be solved in a new bluez release.

If you reproduce the issue, feel free to reopen it.

Status: WontFix

from gimx.