Pls Help with EPOS application using DirectX

[POSitality]

For a bit of fun I'm trying to run a program called "ICR Touch" which is quite popular in the European EPOS industry. It uses DirectX for its rendering which is fairly unusual given the target market.

Anyway, it installed fine and actually runs! I can't really see what's going on on-screen but it responds to keypresses and mouse clicks as I would expect.

I've got the basic log here:

Code: Select all

fixme:heap:HeapSetInformation 0x110000 0 0x32fda0 4
fixme:d3d:wined3d_guess_card No card selector available for card vendor 0000 (using GL_RENDERER "Gallium 0.4 on llvmpipe (LLVM 0x301)").
fixme:win:EnumDisplayDevicesW ((null),0,0x32f6f4,0x00000000), stub!
fixme:d3d:swapchain_init Add OpenGL context recreation support to context_validate_onscreen_formats
err:d3d_surface:wined3d_surface_getdc Not supported on surfaces with application-provided memory.
err:d3d_surface:wined3d_surface_getdc Not supported on surfaces with application-provided memory.
err:d3d_surface:wined3d_surface_getdc Not supported on surfaces with application-provided memory.
err:d3d_surface:wined3d_surface_getdc Not supported on surfaces with application-provided memory.
err:d3d_surface:wined3d_surface_getdc Not supported on surfaces with application-provided memory.
etc...

Logs spew the d3d_surface error continually while the program is running and the screen is mostly black with a few random coloured pixels vaguely where I would expect pop-ups and dialog boxes.

I believe the program desires a 16-bit or 32-bit colour depth (no 24-bit) and, on a real Windows machine, it is quite happy to run on a default VGA driver.

I've tried searching for the error but I'm a complete noob with WINE so any suggestions would be appreciated!

Best Regards,
Andy

[POSitality]

I've chatted to the ICR programmers and they're love to see their program running on Linux

Apparently the surfaces they use are created off-screen in application memory and hence the error. The thing is, if the surfaces AREN'T okay in application memory then the program should fall back to graphics memory gracefully.

I've taken a look at the source code in surface.c and I can see where the error crops up okay (if the SFLAG_USERPTR is set) under wined3d_surface_getdc.

Looking further down, should I be looking at wined3d_surface_create? It doesn't seem to do much other than allocate memory. One of the programmers suggested that the Create Surface function should fail if WINE doesn't like application created surfaces...

Should I even be talking about this here or move on to bug submission?

Regards,

Andy

[lahmbi5678]

What kind of graphics card are you using? If you are on Nvidia or ATI/AMD, you should try to install the closed source drivers for them. If your app actually doesn't need hardware accelerated graphics, the open source radeon or nouveau drivers might work, too.

What's the output of glxinfo, especially the lines containing "dri" or "direct rendering" and "renderer"?

[POSitality]

I've got this running on a Virtual Machine for testing:

Linux Mint 14 32-bit (Xfce desktop manager) on VirtualBox, glxinfo says the renderer is "Gallium 0.4 on llvmpipe (LLVM 0x301)

If I get this working I'd be thinking about production EPOS terminals which normally run a variant of Windows Embedded. Hardware is usually Intel-based with the standard on-board Intel graphics adapter.

Again, on production systems the program doesn't even need a graphics driver beyond Windows built-in VGA one. While the program makes some minor requests of DirectX it really doesn't care if the operations are done in software or accelerated by hardware.

Is it the case that this would run better on "real" hardware rather than virtual? The main error leads me to believe the problem is just over two types of memory allocation.

Regards,

Andy

[lahmbi5678]

"Gallium on llvmpipe" is a pure software renderer, it would be interesting to know, if it would work on real Nvidia/Ati/Intel hardware (without VM). Maybe you could try to configure VMWare Tools to give you hardware acceleration.

The issue behind may very well be a bug in wine or unimplemented functionality in wine or Gallium driver. You probably should file a bug in wine's bugzilla. Is there a free demo/trial version? The wine d3d devs aren't following this list closely (probably would keep them too much from working but they do read bug reports. You also could try to contact them via wine irc, see http://www.winehq.org/irc.

[POSitality]

Just to be on the safe side I've loaded up WINE + Mint on a real EPOS unit and unsurprisingly the same error crops up.

I think I'd best make a bug report

[POSitality]

Update on this problem:

This issue is the original program asking to construct graphics in Application rather than Video memory. While perfectly valid, the request is unusual relative to how other contemporary programs function.

The programmers of the original program have since made compatibility changes and the program now operates in Wine 1.5.x correctly!