Welcome, Guest. Please login or register. Did you miss your activation email?

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - NoobsArePeople2

Pages: 1 [2] 3 4
16
Window / Re: Exposed Joystick Name, Product ID and Manufacturer ID
« on: February 02, 2014, 05:01:03 am »
Today I put my Linux joystick updates to the test in several Linux distros:

  • Ubuntu 13.10 x64
  • Mint 16 Cinnamon x64
  • Manjaro x64
  • Fedora 20 x64

All of these are virtualized in VirtualBox running in a Windows 8 x64 host. For testing I've used an official wired Microsoft XBox 360 pad. On Windows I'm using the official MS driver for the pad and it's passed through to Linux via VirtualBox's USB support.

In all cases udev was installed by default. This is expected as the udev Wikipedia entry notes that udev was merged into systemd in April 2012. It also notes that some Distros like Debian (upon which Ubuntu and Mint are based) ship is separately. In my test, I did the default install for all distros and udev was present in every case so I think it safe to assume udev will be present and running on most Linux distros.

I did however need to install libudev (the development version) in order to have the udev headers. This means the Linux version of SFML will have a new dependency (to go along with pthread, freetype, etc): udev. I've updated CMake to include udev for Linux.

On Windows there was some concern about some macro magic I was doing with _UNICODE. I did some reading on this and found this StackOverflow question which lead to this blog post. The short version is the UNICODE define affects everything in the Windows headers and _UNICODE affects everything in the C runtime headers. So, in order to fully force the Windows version to Unicode both UNICODE and _UNICODE need to be defined.

I've squashed all my changes into a single commit and submitted a pull request here.

Thanks everyone for all the help!

17
Window / Re: Exposed Joystick Name, Product ID and Manufacturer ID
« on: January 26, 2014, 03:19:27 am »
Short version: By using udev I'm able to get the manufacturer and product IDs! See commit. People of Linux, please test and let me know how this works for you.

Long version:

I spent some time digging through the SDL joystick implementation and reading up on iotcl and this is what I've found. SDL looks for joysticks in /dev/input/event while SFML looks in /dev/input/js. This means SDL must use the "EV" iotcls like EVIOCGNAME while SFML must use the "JS" ioctls like JSIOCGNAME. When attempting to mix and match I get EINVAL errors (EVIOCGNAME fails with an EINVAL error in SFML but it's JS counterpart JSIOCGNAME works great).

Unfortunately there is not a JS version of EVIOCGID, the ioctl used for retrieve an input_id struct, and hence the vendor and product IDs. SFML could switch to use /dev/input/event rather than /dev/input/js but it's my understanding that "js" is the more modern way of handling joysticks (also, my install of Ubuntu would get a "permission denied" error when attempting to read "event" which is odd since SDL worked...).

Enter libudev. I had seen mention of udev before in the tracker (here) in which Laurent posted a tutorial for udev. Using it is pretty straightforward and it looks to be the standard way for working with hardware devices on Linux systems. It also provides a really easy way to read vendor and product IDs. The downside is that we've introduced another dependency for the Linux implementation of SFML.

The commit with the udev update uses udev to retrieve the vendor (manufacturer) and product IDs and the JSIOCGNAME ioctl to get the joystick name. It also updates Cmake to link udev when compiling SFML on Linux.

While the Cmake update works I'm not really sure it's the best way to do it. A cursory google yields a FindUDev.cmake file. Honestly, I don't know enough about Cmake to know the best way so I guess reading up on that is next ;)

18
Window / Re: Exposed Joystick Name, Product ID and Manufacturer ID
« on: January 24, 2014, 08:13:14 am »
I've created a simple SDL app to read joystick names and GUIDs. SDL doesn't have an API for something like getJoystickVendorID(), instead you read the GUID. For Linux you can see the GUID implementation here.

My test app is on Github here.

Using my wired 360 controller on Ubuntu (running in a VM) I get the following output from my SDL test app:

Name: Microsofy X-Box 360 pad
GUID: 030000005e0400008e02000014010000

If I'm reading the SDL source code correctly this means SDL sees the vendor ID as "5e04" and the product ID as "8e02". SDL forces bytes into a little endian representation so these might typically be written as "0x045e" and "0x028e" which match what lsusb -v outputs for me:

...a bunch of stuff...
idVendor: 0x045e
idProduct: 0x028e
...a bunch more stuff stuff...

So SDL looks to be getting the correct values. With my latest commit (see here) my vendor/product ID reading is essentially identical to SDL's yet I'm still seeing EINVAL when attempting to read the EVIOCGID ioctl.

I think we should be able to get the correct values (at least with the 360 pad anyway). Going to keep digging on this.



19
Window / Re: Exposed Joystick Name, Product ID and Manufacturer ID
« on: January 22, 2014, 10:08:19 pm »
Awesome! Thanks for the details.

20
Window / Re: Exposed Joystick Name, Product ID and Manufacturer ID
« on: January 22, 2014, 07:23:15 pm »
@Antidote

Good to know. Perhaps it's driver related then. Can you post a list of the devices that do and don't work? Are you running in a VM?

21
Window / Re: Exposed Joystick Name, Product ID and Manufacturer ID
« on: January 21, 2014, 10:25:28 pm »
So I tried that with no joy. Do we know that SDL's implementation works?

From my reading using struct before the declaration is related to C syntax (getting this from StackOverflow). The chosen answer for the question states that using the struct keyword in this way restricts the identifier lookup to user defined classes. This seems odd as we want to use the input_id defined in the standard Linux headers. Maybe I'm understanding that wrong? That SO post points to some further reading here.

I'm a little under the weather right now so I'm planning on giving this a fresh look later this week. I think the next thing I'll do is compile SDL on Linux and see what their implementation gives me. My reference article is over tens years old, things may have changed.

Agreed on the renaming stuff to match SFML conventions.

22
Window / Re: Exposed Joystick Name, Product ID and Manufacturer ID
« on: January 20, 2014, 06:48:23 pm »
I was able to get a hold of a joystick. Now i just need to find some time :D I will try to do some testing this week.

Woohoo! I haven't looked in a few days, but I'm stumped on getting the vendor and product IDs so any thoughts you have there are welcome.

23
Window / Re: Exposed Joystick Name, Product ID and Manufacturer ID
« on: January 17, 2014, 02:59:06 am »
Your JoystickInfo.name settings sound good to me. I'll make the change.

It'd be great if you could get a joystick for testing.

24
Window / Re: Exposed Joystick Name, Product ID and Manufacturer ID
« on: January 16, 2014, 07:42:52 am »
Also not sure about the UNICODE macro magic, since all versions of Windows being supported got the full wide char set implemented (so just use that).

So I tried removing the _UNICODE macro and explicitly using all the wide char set versions of the functions for reading the registry (e.g., RegQueryValueExW instead of RegQueryValueEx). These work fine except that the registry key REGSTR_VAL_JOYOEMNAME is not wchar_t but rather char_t so I get an error.

Maybe the problem is that I'm using Mingw? It looks to me like Cmake is setting a UNICODE macro when building SFML on Windows but the Mingw headers are using a _UNICODE macro. Does that sound plausible? If that's the case what's the best way to go about handling this situation?

25
Window / Re: Exposed Joystick Name, Product ID and Manufacturer ID
« on: January 16, 2014, 07:35:25 am »
To answer the question: I also use a virtual machine (VirtualBox) and Ubuntu. The host machine is a win 8. And I didn't run into any problems yet.

Lucky you ;) I installed VB and it promptly disabled my ethernet adapter so no internet. "Okay", I thought, I'll just restart. That should fix it! Then Win8 sat at the boot screen for 30 minutes. So I cut the power by holding down the power button...which can apparently cause issue with my SSD such that the system cannot recognize it until you power cycle the SSD which takes an hour. Anyway, there was lots of swearing and I ended up getting myself a nice beer but I did eventually get it to work!

I've made some comments on Github but I'll recap here. On Ubuntu 13.10:

I'm able to get the joystick name no problem ("Microsoft X-Box 360 pad" in this case).
I'm not able to get the vendor or product IDs. It's probably something simple but I'm not seeing it.

Quote
I also agree that "Unknown Joystick" might be a bit confusing, but that again one should check beforehand with sf::Joystick::isConnected if the Joystick is even connected.

So there's two ways this gets set:

1. It's the default value for a new JoystickInfo struct.
2. A joystick gets connected, SFML tries to read the value but errors out for some reason. In this case SFML sets the name to "Unknown Joystick".

After having debugged an issue on Linux that was not obvious because JoystickInfo.name defaulted to "Unknown Joystick" I'm in 100% agreement that this is confusing (was about 96% before ;) ). In the second case I think SFML should set some known, default value that can be interpreted as "I tried and failed".

I've changed the first case to an empty string ("") and left the latter alone.

26
Window / Re: Exposed Joystick Name, Product ID and Manufacturer ID
« on: January 13, 2014, 06:28:38 pm »
Quote
Try the Ubuntu windows installer.  You can dual boot without having to change partitions.  And you can even uninstall it if you don't like it.

http://www.ubuntu.com/download/desktop/install-ubuntu-with-windows

That looks awesome! I think I'm going to try VirtualBox first, it being the path of least resistance and all but I do want to get a non-virtualized version of Linux up and running at some point.

Any experience using this with Windows 8 (Win8 seems to frustrate dual-boot setups)?

27
Window / Re: Exposed Joystick Name, Product ID and Manufacturer ID
« on: January 13, 2014, 06:26:26 pm »
If you've got a not too old CPU with virtualization instructions, I'd just use virtualization to boot a Unix installation while you're in Windows (Core 2 Quad is more than enough, although an i-7 will get you almost native speeds).

I'm using Linux Mint inside Virtual Box and it runs flawlessly. No need to worry about dual booting. Although I've used Wubi in the past, I think it might cause problems with newer systems and secure boot. Other than that, it's pretty safe to use, just like any Windows program. Just make sure to stay away from partitioning tools and things such as Grub while under Unix.

I'll give VirtualBox a try. I've been using Hyper-V as it ships with Win8 Pro but it lacks USB support. I'm running an i7 so it sounds like VB should run great.

Quote
While I haven't tried it, just out of interest: Do you even have to go through the registry to get the name under Windows? The JOYCAPS structure already got a name field. Although I'm not sure how accurate this is or if it's still populated.

Unfortunately you do. I don't remember the exact value JOYCAPS gives but it's something like "USB Joystick" for every device I tried.

Quote
Also not sure about the UNICODE macro magic, since all versions of Windows being supported got the full wide char set implemented (so just use that).

I can switch it but it looked to me like SFML is setting a similar macro via CMake to force Windows to Unicode mode so I was trying to go with the flow there and no require Unicode functions.

Quote
Plus I think it shouldn't return "Unknown Joystick" if a device isn't present/connected at all.

It should only return "Unknown Joystick" if the joystick is connected but we fail to read the name value for some reason. My thought here is that we should return some known value and allow the joystick to function even if we can't suss out the name. Maybe there's a better way to handle this case?

28
Window / Re: Exposed Joystick Name, Product ID and Manufacturer ID
« on: January 13, 2014, 04:59:52 am »
This looks good!
:)
Sadly I don't have a joystick here to test it.
:(

I've posted to the #152 ticket on Github with a note about this thread.

As an aside, are you running Linux? In a dual-boot setup with Windows perhaps? I'd like to get something like that setup so I can properly test Linux stuff but all the guides I've read make me a bit worried that I might hose my Windows install.


29
Feature requests / Re: Joystick information
« on: January 07, 2014, 07:37:23 pm »
Hey Guys,

I have a post about this over in the Window sub forum. I've implemented the feature from the Github ticket Laurent referenced and would like to have some people test it out (specifically on Linux) before I submit a pull request.

30
Window / Exposed Joystick Name, Product ID and Manufacturer ID
« on: January 04, 2014, 04:59:41 am »
I've made an update to expose the name, product ID and manufacturer ID for joysticks. This is ticket #152 on Github. The commit with these changes is on my fork of SFML.

I'm a C++ noob so I'd like to get a good code review of this change before doing a pull request. Also, I haven't been able to properly test this on Linux (it compiles in VM but by VM software doesn't allow me to connect USB devices) so I'm not certain it functions properly on that platform. If a pull request is preferrable to this forum post let me know and I can do that.

The Changes

JoystickCaps has been renamed JoystickInfo. In addition to the name change three properties have been added to it:

1. name: the name of the joystick.
2. manufacturerID: the joystick manufacturer's ID.
3. productID: the product ID of the joystick.

sf::Joystick has three new functions that correspond with these values:

1. getName(unsigned int index): return the name of the joystick at index as an sf::String.
2. getManufacturerID(unsigned int index): returns the manufacturer ID at index as an unsigned int.
3. getProductID(unsigned int index): returns the product ID at index as an unsigned int.

Testing

I've been using this update on Mac OS and Windows for awhile and all is well (for me anyway). The Linux implementation compiles but I'm running Ubuntu in a virtual machine and am unable to connect USB devices to it so I cannot put it to the test.

Platforms

On the Mac side of things I'm running 10.7 Lion with Xcode 4.6. I'm compiling with C++11 support using Clang.

On Windows I'm running Windows 8 x64 with Mingw 4.6.2.

On Ubuntu I'm running 13.10 x64 with GCC 4.8.x.

Controllers

I've tested with the following controllers (drivers listed in instances were the manufacturer does not provide one for the platform):

- Xbox 360, wired (Windows, Mac via Tattiebogle v0.08 Driver)
- Xbox 360, wireless (Windows)
- PS3 (Windows via Motioninjoy v0.7 Driver, Mac)
- Wiimote, no attachments, with nunchuck, with classic controller (Mac via WJoy v0.7.1 Driver)



I feel good about the Mac and Windows implementations. Can someone please give the Linux version a try and let me know how/if it works?

Pages: 1 [2] 3 4
anything