WiiLi.org

[Snark]

I recently bought a classic controller attachment for my wiimote and I decided to test it out with wmgui.

Before you read on, I just want to add that I understand if the problem I am about to address is a low priority considering all the other things you are working on.

As the topic title says, I got some nasty lag. The corresponding button presses on the classic controller were registered, but at a delay of ~4-5 seconds. Application redraw as well as pointer movement also exhibited severe lag, but that only happened the first time I tried it.

None of these problems occurred until I started pressing buttons on the CC extension.

Abstrakraft, I could do further testing if you like. I realize that you might not have your own extensions to test with, so just tell me what you want me to play with. It might only be a problem with wmgui, but I really haven't familiarized myself at all with wminput. As far as I can tell, there isn't any CC support in wminput for cwiid 4.0.1.

I do not own a nunchuck.

[abstrakraft]

Weird.....I've got a nunchuk and classic controller, and I've never run into the problem you describe. One of the main sources of complexity in wiimote is the thread synchronization and my psychotic paranoia of any sort of polling, so I don't know of anything that could steal enough processor time to delay redraw and pointers.

I got nothing - is there anything at all unusual about your setup?
_________________
"I seldom let practicality get in the way of my fascination with shiny things and blinky lights."
- some guy
http://abstrakraft.org/cwiid

[Snark]

Unusual? I don't think so. Like what? Be more specific.

Here's the funny part: If I unplug the CC extension, untick the accelerometer display, or untick the CC display, everything eventually goes back to normal. In other words, all three conditions are needed for lag to happen; remove one condition and it's all fine.

If I had to guess, I'd say it's definitely not the wiimote or the CC. The above seems to suggest that.

The digital(?) shoulder button readout is also acting odd. The initial values - nothing pressed - look somewhere around 10% pressed, and the left one shows as slightly less than the right one.

I have probably reproduced this lag 10-15 times now trying to figure it out (it happens every time without fail) and the redraw/pointer problem hasn't happened again. So you can probably stop worrying about that much at least- something else unrelated to cwiid probably caused it.

[abstrakraft]

The unusual part was deliberately open-ended - I'm digging for data.

[EDIT: As far as I know, ] That's normal for the L/R buttons - any app using them has to do its own calibration.

My best guess at this point is a GTK problem - what version are you running? As soon as I get wminput rewritten and released, you can test it's responsiveness to verify or disprove that guess.
_________________
"I seldom let practicality get in the way of my fascination with shiny things and blinky lights."
- some guy
http://abstrakraft.org/cwiid

[Snark]

[abstrakraft]

"Unusual" things - any unusual kernel config parameters, particularly those dealing with real-time and preemption. Other bluetooth devices. Unusual peripherals, particularly those requiring CPU time. Other applications with heavy CPU, network, file, bluetooth, or USB activity.

I can't reproduce it on my laptop (primary dev platform), I'll try my desktop when I get home. I'm running gtk+-2.10.6, no idea if that has anything to do with it or not - can you try upgrading?

Can anyone else reproduce this behavior? If so, what gtk version are you running?

One other thing to check - what does your CPU activity look like while the display is lagging?
_________________
"I seldom let practicality get in the way of my fascination with shiny things and blinky lights."
- some guy
http://abstrakraft.org/cwiid

[Snark]

I finally have a nunchuck. Same thing happens with that.

CPU usage goes all the way up to the roof whenever the lag is going on.

It's definitely something to do with the constantly updating progress/percentage bars being used. For some reason, it can't handle displaying data from more than 1 source at a time. Otherwise, if I keep everything still, I have no problems pressing all the buttons I want without getting lag.

There's nothing unusual about my kernel as far as I can tell. It's merely a stock debian kernel.

The only thing I can think of is that I am using a usb bluetooth stick. Maybe my usb can't handle all the data at once. I doubt it though, but I wonder how to check for that anyways.