Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Mouse movement commands getting buffered? #9

Closed
matlo opened this issue Nov 27, 2013 · 36 comments
Closed

Mouse movement commands getting buffered? #9

matlo opened this issue Nov 27, 2013 · 36 comments
Labels
bug imported wontfix

Comments

@matlo
Copy link
Owner

matlo commented Nov 27, 2013

From dmcreyno...@gmail.com on May 07, 2010 21:10:48

What steps will reproduce the problem? 1. Compile/Run Program
2. Tested with Battlefield: Bad Company 2
3. For example move the mouse slowly in one direction, stop moving the
mouse, then press X (jump). The X command will not execute until all
movement commands have been sent to the PS3. What version of the product are you using? On what operating system? Ubuntu 10.04 LTS
diyps3controller revision 53 Please provide any additional information below. Although I can see the logic in what is happening, it doesn't make FPS
games very playable if I have to wait around for my mouse commands to clear
the buffer. Keyboard commands as far as I can tell so far have been
working well, as they only send one command to the system.

Original issue: http://code.google.com/p/diyps3controller/issues/detail?id=7
@matlo
Copy link
Owner Author

matlo commented Nov 27, 2013

From mathieu....@gmail.com on May 07, 2010 13:41:46

Summary: [v2] Mouse movement commands getting buffered?

@matlo
Copy link
Owner Author

matlo commented Nov 27, 2013

From mathieu....@gmail.com 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.

@matlo
Copy link
Owner Author

matlo commented Nov 27, 2013

From dmcreyno...@gmail.com 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.

@matlo
Copy link
Owner Author

matlo commented Nov 27, 2013

From mathieu....@gmail.com on May 08, 2010 03:26:35

Labels: -Priority-Medium Priority-Critical

@matlo
Copy link
Owner Author

matlo commented Nov 27, 2013

From mathieu....@gmail.com 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 .

@matlo
Copy link
Owner Author

matlo commented Nov 27, 2013

From mathieu....@gmail.com 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.

@matlo
Copy link
Owner Author

matlo commented Nov 27, 2013

From mathieu....@gmail.com on May 08, 2010 05:39:45

Status: Accepted
Owner: mat....@laposte.net

@matlo
Copy link
Owner Author

matlo commented Nov 27, 2013

From dmcreyno...@gmail.com on May 10, 2010 00:20:57

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

@matlo
Copy link
Owner Author

matlo commented Nov 27, 2013

From mathieu....@gmail.com 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.

@matlo
Copy link
Owner Author

matlo commented Nov 27, 2013

From dmcreyno...@gmail.com 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

@matlo
Copy link
Owner Author

matlo commented Nov 27, 2013

From mathieu....@gmail.com 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)

@matlo
Copy link
Owner Author

matlo commented Nov 27, 2013

From dmcreyno...@gmail.com 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

@matlo
Copy link
Owner Author

matlo commented Nov 27, 2013

From mathieu....@gmail.com 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?

@matlo
Copy link
Owner Author

matlo commented Nov 27, 2013

From dmcreyno...@gmail.com 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.

@matlo
Copy link
Owner Author

matlo commented Nov 27, 2013

From mathieu....@gmail.com 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!

@matlo
Copy link
Owner Author

matlo commented Nov 27, 2013

From dmcreyno...@gmail.com 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!

@matlo
Copy link
Owner Author

matlo commented Nov 27, 2013

From mathieu....@gmail.com 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!

@matlo
Copy link
Owner Author

matlo commented Nov 27, 2013

From mathieu....@gmail.com 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?

@matlo
Copy link
Owner Author

matlo commented Nov 27, 2013

From mathieu....@gmail.com 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.

@matlo
Copy link
Owner Author

matlo commented Nov 27, 2013

From mathieu....@gmail.com 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.

@matlo
Copy link
Owner Author

matlo commented Nov 27, 2013

From dmcreyno...@gmail.com on May 11, 2010 10:21:19

Thanks, I will test as soon as possible.

@matlo
Copy link
Owner Author

matlo commented Nov 27, 2013

From jimatj...@gmail.com 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.

@matlo
Copy link
Owner Author

matlo commented Nov 27, 2013

From mathieu....@gmail.com 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...

@matlo
Copy link
Owner Author

matlo commented Nov 27, 2013

From mathieu....@gmail.com 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.

@matlo
Copy link
Owner Author

matlo commented Nov 27, 2013

From mathieu....@gmail.com on May 12, 2010 01:38:07

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

@matlo
Copy link
Owner Author

matlo commented Nov 27, 2013

From mathieu....@gmail.com on May 12, 2010 09:49:49

Debug traces added at the good place.

@matlo
Copy link
Owner Author

matlo commented Nov 27, 2013

From dmcreyno...@gmail.com 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

@matlo
Copy link
Owner Author

matlo commented Nov 27, 2013

From mathieu....@gmail.com on May 12, 2010 16:59:06

Thanks.

Please perform actions described in Comment 22.

@matlo
Copy link
Owner Author

matlo commented Nov 27, 2013

From dmcreyno...@gmail.com 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

@matlo
Copy link
Owner Author

matlo commented Nov 27, 2013

From mathieu....@gmail.com 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.

@matlo
Copy link
Owner Author

matlo commented Nov 27, 2013

From mathieu....@gmail.com 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

@matlo
Copy link
Owner Author

matlo commented Nov 27, 2013

From dmcreyno...@gmail.com on May 20, 2010 08:08:39

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

@matlo
Copy link
Owner Author

matlo commented Nov 27, 2013

From mathieu....@gmail.com 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

@matlo
Copy link
Owner Author

matlo commented Nov 27, 2013

From mathieu....@gmail.com 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.

@matlo
Copy link
Owner Author

matlo commented Nov 27, 2013

From mathieu....@gmail.com on January 27, 2011 08:25:18

Summary: Mouse movement commands getting buffered?

@matlo
Copy link
Owner Author

matlo commented Nov 27, 2013

From mathieu....@gmail.com 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

@matlo matlo closed this as completed Nov 27, 2013
@matlo matlo mentioned this issue Nov 27, 2013
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug imported wontfix
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@matlo