Setup of Wii Remote

[cleardata]

Sounds about right, I imported a bunch of my videos and that's when it started happening.  when i get home I'll check that as well. 

[piusvelte]

So I figured out how to get scrolling to work with the wiimote. I'm using a sensor bar with /etc/cwiid/wminput/ir_ptr. This includes the buttons config. When I'd try to scroll, the cursor would go to the bottom of the screen and nothing would happen. To get scrolling to work, you have to add in the acc_ptr config. I just added these lines from acc_ptr to the ir_ptr file:

Code: [Select]

Plugin.acc.X = REL_X
Plugin.acc.Y = REL_Y
Now I can scroll through my music/videos etc. I'll add this to the wiki.

[tschak909]

Instead of hacking it together, why don't some of you spend some time actually properly integrating it into LinuxMCE?

-Thom

[piusvelte]

Thom,

I'd be glad to contribute to LMCE. How do I properly get started? I don't want to cause any disruptions or grief for the real developers!

Thanks!

[tschak909]

Real developers?

the "Real Developers" as you put it, merely are people who just buckle down and do the work to make things better for others.

We have a very basic rule here. "He who does the work, has made the rules."

(yes, that wording is very specific, think about it.)

You need to first spend some time reading the Developers guide on the wiki. Also look at Device Templates

-Thom

[pigdog]

Hi all,

I've been using the wiimote on alpha 2 and it works much better than on 710.

For scrolling works thru movie pages, just use a light touch or wrist flick for scrolling to the next page.

Keeping it pointed to the bottom/top right will produce multiple scroll arrows.

I had no problems on initial setup. No need to modify plugin.acc.

I've got a ir light bar for tracking.

The only real problem is making sure you have good batteries in the 'mote.

Cheers.

[tschak909]

Will somebody do the legwork, based on the HID remote notes I have dumped in the Gyration thread, and make a device template that uses wminput to handle the wiimote? preferrably someone who has a mobile orbiter in use?

-Thom

[mactalla]

Will somebody do the legwork, based on the HID remote notes I have dumped in the Gyration thread, and make a device template that uses wminput to handle the wiimote? preferrably someone who has a mobile orbiter in use?

First of all, please forgive me for any noob questions.  I can get around Linux and C++ well enough, but I'm very new to LinuxMCE with a recently setup core, MD, wiimote and no orbiter.  Ideally these questions are already answered somewhere and you can just point.  However I have not yet found them.  When things make sense, I think a clear step-by-step wiki page is in order.  I can certainly help with that.

I appreciate the valuable info you put in the other thread.  Could you point me to additional information for creating device templates?

I took a stab at a device template based on what I could find in the wiki, which sadly wasn't much.  I looked at the webadmin for creating device templates and aside from not understanding many of the fields, based on comments in the forums here it seems clear that's only one piece of the puzzle.

As a starting point, I would like to know the top-level flow of events and from there can ask more informed questions / more likely to figure things out on my own.

Let's take our case here of the Wii remote.  I assume there are two levels of polish for the device template for lack of a better term.  The first would be to have the buttons do what we want (ala create a Play/Pause key being the top priority here, methinks).  The more complete version would also handle creating the wminputd script, wminputd.conf, etc as described on the wiki so that when it's detected all those things are setup automatically.  Am I correctly understanding the scope of responsibility for device templates?

Let's focus on the first level of polish as the remainder is clearly laid out on the wiki and should be easy to automate.

My first question is associating a device with a template.  When creating the template I see you can specify a MAC range, etc.  How can I tell that the device has been associated with the template?  I assume one of the log files would contain that info?  Where/which one?

When a template is loaded it reads the mapping and configuration as you pointed out in your post.  Mapping is irrelevant for the Wiimote task as the wminputd.conf is doing the mapping.  So configuration is the only one we're interested in for this case.

You mentioned the syntax for configuration is:
RemoteMapping_Entry,x scancode,UDH,Y

The UDH,Y portions are clear (thanks to your post).  x scancode is the same as keycode, correct?  For some reason I thought scancodes were more raw than even keycodes, but xev is only showing the keycode and keysym, so perhaps I'm mistaken there.

The RemoteMapping_Entry I'm not clear on.  You provided an example of a RemoteMapping entry early in your post, but I missed where this is actually defined, whether this needs to be defined for every template, or where to find the list of existing mappings for standard actions (like Play/Pause).

Now with those pieces, it looks like making the right entries in #59 Configuration - Default Value would do the trick (assuming there's an existing RemoteMapping to point to).

So where do the changes for bluetooth & bluetooth_dongle code enter the picture?  (Your post here: http://forum.linuxmce.org/index.php?topic=4755.msg51423#msg51423 said those are needed too).

Long post, but I hope it makes sense.  I'll write a wiki article when I understand things myself.

[tschak909]

Sorry, I will write more when I get a free moment, but to ansewr a quick question, scancode = x key code.

I will try to explain other bits better when I get the chance.

But basically, you have a device template, this contains the following:

* Device name
* How it relates to other devices (can it be attached to a core, or a MD, to other devices, etc?)
* A package for this device driver, so that it can install what it needs for drivers, etc.. This is explained on the Packages wiki page.

Once you have this, you then have, Device Data. Think of this as a place to store configuration for a device. These fields are arbitrary, and are used by different parts of the system at different times by database queries. These are parameters, and states, some of them can be changed by user, some should be hard set, etc.

You then have a set of commands that the device can respond to. This only makes sense if you're making a DCE device to wrap things and want to send commands to it.

This brings me to another point, some device templates are not DCE devices, but are indeed places to store information in templates. Sometimes our scripts check for the presence of certain devices, and do things based on it. Such templates also have pointers to various scripts to set things up when needed.

You then have events that the device can emit to the system. Again, for the DCE devices.

After this, you have the PNP subsystem, this basically allows you to put records in the database that the Plug and Play Plugin will match. In the case of bluetooth devices, plug and play events come from the Bluetooth Dongle, and match fields in this area. The relevant info is the MAC address field. If you put 0 and 0 in the from to, it will match all MAC addresses like our other bluetooth devices, and you'll have to explicitly select WiiMote from the device list like with other phones.. if you KNOW that there is a range for a particular device, you can limit it to those devices, and get a simpler screen....

also keep in mind there are other device data parameters that will cause the PNP screens not to appear, look at the bluetooth dongle device template. If you can determine enough data, configuration screens will not appear.

-Thom