XMBC vs. wine in linux

[boskar]

As You already know, (look for my posts;) I'm linux user and I like to play some games under wine

It've got a crazy idea: to use more buttons in XMBC under wine by breaking/extending windows API compatibility.
Windows sucks in case of extra mouse buttons (as it doesn't support enough buttons by default), Linux is a little bit better here.
Button clicks, wheel, side button, extra button (office button in my case) are suported by simple ButtonPress/ButtonRelease with button = 1, 2, etc. (in my case 1,2,3,4,5, 8,9,10 - 6,7 probably reserved for second wheel or something).

Wine translates those events to windows api events. As wine is open source we are allowed to create any modifications, patches etc. It should be quite simple to add dirty support for normally unsupported buttons by modyfing just a few files here: http://source.winehq.org/git/wine.git/t ... inex11.drv → mouse.c and events.c and some others... windows/input.c probably.

XMBC on the other hand is closed source - It's OK as it's free to use, well maintained and actively developed. XMBC seems to be the only program that might be able to catch those events and bind some functions to them, but it won't work without code modifications of XMBC.

I've tried to modify wine to send dwExtraInfo as described here: viewtopic.php?f=6&t=497 but I failed miserably (maybe because I cannot code, simpy? )

Maybe You, Phil, would like to cooperate here and add patches to your program and release alpha quality wine-flavour of XMBC?

We might use simple dwData as for side mouse buttons, or some other stuff - You know a lot about mouse api in windows and would like to suggest the best solution.

And, as always - it's just an idea, in this case very crazy idea.
PS. Probably patches for wine for this stuff won't be included in main wine tree - but it'd still be useful for those who can patch wine manually.

[phil]

Well its certainly an interesting idea, but the main problem i have is that the gui work would be massive. The behind the scenes, button work probably would be quite easy, esp. if you can use the dwData like the 4th and 5th side buttons, but the gui configuration, for me, would make it complex enough to be not worth it - esp as I dont use linux/wine and there havnt not been to many others requesting such features.

It might however be possible to do the back end work, and leave the config to manually editing the XML configuraiton file for now. I dont know - no promises but that will probably be less work.

But not knowing the environment, it might take me some time to get up to speed again with linux and with wine which I have never used.

Thanks,
Phil

[boskar]

We may start with just one button using Office Mode of XMBC - just to prove this idea works - as this mode is already implemented, You won't need to modify GUI at all.

If we succeed, we will think about further buttons.

[phil]

Except in office mode, you don't get any tilt support. If you can live with that, then I would suggest trying to patch wine to use the existing officemode code (thus no changes in XMBC!). I know you tried but maybe some more detail about how it works might help?

[phil]

PS. Either way, don't expect me to be able to make changes any time soon, my spare time for XMBC is almost none right now what with work and other commitments.

[boskar]

Ok, We're almost there.

XMBC log: http://pastebay.com/126784

modified mouse.c : http://pastebay.com/126785
(modifications:
line 70 → to increase total
72-126 as for middle mouse button,
1327 - 1331 and 1356-1360 added. )

XMBC ignores dwExtraInfo = 0x400 - it's detected as normal middle mouse button click.

When i tried to inject dwExtraInfo in button release also, release event of the button middle button was not detected at all in office mouse mode.

[phil]

OK this is very interesting... You might have found a bug - maybe it no longer works for office mouse too (I don't have one to test). but looking at the code.......

Code: Select all

	case WM_MBUTTONUP:
	case WM_NCMBUTTONUP:
		if (g_bOfficeMouse && (msllh->dwExtraInfo & 0x0400))
			bResult = ProcessButton(OFFICEMOUSE_MIDDLE2, BTN_UP, msllh->pt, bFooBar);
		else
			bResult = ProcessButton(MIDDLE, BTN_UP, msllh->pt, bFooBar);
		break;
	case WM_MBUTTONDOWN:
	case WM_NCMBUTTONDOWN:
		if (g_bOfficeMouse && (msllh->dwExtraInfo & 0x04))
			bResult = ProcessButton(OFFICEMOUSE_MIDDLE2, BTN_DOWN, msllh->pt, bFooBar);
		else
			bResult = ProcessButton(MIDDLE, BTN_DOWN, msllh->pt, bFooBar);

Either I gave you duff information previously OR Ive broken the code, the mousedown is looking for 0x04 not 0x0400, where the mouse up is looking for 0x0400.

I will have to try and dig through the source history and see if its wrong or if the info I gave is wrong.
I will get back to you on that!

Thanks,
Phil

[phil]

DOH!

My mistake - and I'm very sorry for wasting your time.

Officemouse mode is indeed looking for 0x04 on the mouse down message and 0x0400 on the mouse upmessage. This is as intended.

Now you know this you might be able to get it working.
If you need more assistance with the wine patch then let me know and I guess (maybe) I can install a virtual machine with Linux and wine on it??? (but thats not going to be a quick job for me probably).

Thanks,
Phil

[boskar]

It's working!

Currently I don't have mouse with more buttons - but in linux we might get them quite easily and translate to use them in XMBC.

My mouse doesn't have tilt wheel, it is unsupported by wine itself, so Office mode is just perfect for me.

[phil]

So on the wine file, if you havnt already worked it out...

referring to your pastebay file (modified mouse.c : http://pastebay.com/126785)

change line 1330 to

Code: Select all

input.u.mi.dwExtraInfo = 4;

Add after line 1358:

Code: Select all

input.u.mi.dwExtraInfo = 1024;

Then officemode might work

EDIT; lol, too late!
Glad its working. More buttons will be difficult GUI wise as I said so for now I hope no one asks for it

[boskar]

Everybody asks for more buttons, the problem remains the same - Windows does not support them natively.

I don't know how does the linux driver for razor mouses (or other multi-button) is written - hopefully every extra button is supported in the same way as the others - if requested we may get them.

Thank you for the cooperation (and one more time for the great program!)

Next checkpoint is: http://bugs.winehq.org/show_bug.cgi?id=25282 - wine Direct3D related bug?

I will test it in a few days.

[phil]

That one looks a little more complicated!
Just to check though,, does it work as expected on Windows (no linux/wine involvment)?

Some games do not work well with mouse hooks in widnows either, because they like to go lower to prevent hooks used by cheaters I guess.

Phil

[boskar]

Yes it does (tested under Windows 2003 and XP Home) - so probably it's a wine bug.
It may have been fixed recently - half a year is a lot of time in such a dynamic project like wine.
I'll install Warcraft in wine ~next week and retest the issue.

[phil]

So how good is wine at running windows apps, what can and cant it do?
Last time I even looked it was only just starting up and was pretty much useless, but it seems if you can play games on it its come a long way!?

I probably wont rush and look into it simply because of familiararity with windows and thats I have to keep developing windows apps but I guess it cant help to keep up with these things

[boskar]

For me currently:
MS Office 2007 SP2 works almost perfectly - I use it daily.
Games - still performance is lower espiecially if the game does not support OpenGL mode.
I've played Warcraft 3 (only issue - described with XMBC), Counter Strike 1.6 runs perfectly for ages, almost every Source-engine game works very good (Portal, CS:Source, L4D... apart from Left4Dead2, which gave me 1 fps @GeForce 8800 GT and Core 2 Quad, but it was a year ago). Direct 3D is under constant development - but if it's possible OpenGL should be used.

Some applications are still unusable - newer versions of Visual Studio, for example.

Fisrt time I believed that this project might be succesful was when I've seen IE6 and Windows Update via ActiveX. Wine even passed WGA for me

Currently, a lot of work is done in mshtml library, msi is almost done... If someone doesn't use complex Windows programs wine may be sufficient.

http://www.winehq.org/status might be interesting for You. But You know, some features are simply not implemented - as for example tilt wheel.

What's quite interesting - a recent idea to add direct support to USB devices, bypassing linux drivers. Of course those devices in this mode would be supported in wine sandbox only - but it'd be useful.

.NET is supported via winetricks - i.e. using .NET enviroment for windows - integration with mono (native linux .net implementation is planned).

And still, nobody should expect that the program will work out of box in wine. Sometimes DLL overrides must be set, sometimes even downloaded via winetricks, OpenGL mode should be forced, etc....

What I've noticed, especially quasi cross-platform applications written in Qt does not work.


And what I've noticed about our wine patch and Office Button support - When I press (and hold) MMB and later MMB2 everything is OK, but when I start with MMB2 (MMB2 is down) and later I press MMB the state of MMB2 is set to up, desping being down.