Maximizing Trackball Buttons

[MariuszXC]

No, FGMouseInput.cxx is one of source code files, used to build the fgfs binary you are using.
It is *not* part of a binary distribution.

Line 51 of src/Input/FGMouseInput.cxx contains this setting:

Code: Select all

const int MAX_MOUSE_BUTTONS = 8;


If you know how to build FlightGear from source you may experiment with changing this number and recompiling, but first you must be sure that underlying software (OS and driver) is correctly reporting events for every button.

[innactpro]

No, FGMouseInput.cxx is one of source code files, used to build the fgfs binary you are using.
It is *not* part of a binary distribution.

While looking into FGMouseInput.cxx, that was becoming more and more obvious. Thank you for clarifying.

[polly]

I suppose I would temporarily change the button assignments for [0] - [4] in mice.xml to see if those are getting through from the trackball.

[innactpro]

It may very well be me making the changes incorrectly, though modifying mice.xlm has no impact on what each button does.

What exactly should be the result of <script>print('button 5 pressed')</script>? Just the words "button 5 pressed" appearing on screen?

[polly]

Yes, in the terminal window, console. I'm probably confusing the issue because I run flightgear from a terminal window with a command line. Choose any binding you want, even copy and paste the binding for one of the buttons already there in mice.xml, maybe with a different viewpoint. I was trying to think of something that would be easy to show that the support for at least four buttons from the trackball is there.

These are alternative functions from Nasal/view.nas, hoping they work.

Code: Select all

   <button n="5">
    <binding>
     <condition>
       <and>
         <property>/devices/status/mice/mouse[0]/button[2]</property>
         <not><property>/sim/mouse/right-button-mode-cycle-enabled</property></not>
       </and>
     </condition>
      <command>nasal</command>
      <script>view.panViewPitch(10)</script>
    </binding>
   </button>
 
   <button n="6">
    <binding>
     <condition>
       <and>
         <property>/devices/status/mice/mouse[0]/button[2]</property>
         <not><property>/sim/mouse/right-button-mode-cycle-enabled</property></not>
       </and>
     </condition>
      <command>nasal</command>
      <script>view.panViewPitch(3o)</script>
    </binding>
   </button>
 
   <button n="7">
    <binding>
     <condition>
       <and>
         <property>/devices/status/mice/mouse[0]/button[2]</property>
         <not><property>/sim/mouse/right-button-mode-cycle-enabled</property></not>
       </and>
     </condition>
      <command>nasal</command>
      <script>view.resetView</script>
    </binding>
   </button>
 




[polly]

Edit The above is wrong, there are semicolons missing from the end of the print statements and, in any case, I can't see them working here. I'd forgotten, too, the Right Mouse button causes the 'Mouse Mode' to cycle and the button behaviour is affected by a menu item: F10-File-Mouse Configuration.

So these look safe:

Code: Select all

   <button n="3">
    <binding>
      <command>nasal</command>
      <script>view.panViewPitch(20);</script>
    </binding>
   </button>
 
   <button n="4">
    <binding>
      <command>nasal</command>
      <script>view.panViewDir(20);</script>
    </binding>
   </button>
 
   <button n="5">
    <binding>
      <command>nasal</command>
      <script>view.resetViewDir(20);</script>
    </binding>
   </button>
 


But they would be pasted into the 'mode' sections of the mice.xml, the cursor shows Arrow, Crosshair, Left-Right for the modes.

[innactpro]

Modifying mice.xml for button 0 to reset the view in mode 0 worked. Restoring mice.xml removed view reset from button 0 in mode 0 as expected.

Modifying mice.xml for buttons 5-7 to reset the view in mode 0 did not work. Also a little as expected because FG has been recognizing input from those buttons as button 0. So it still seems that before mice.xml even gets involved, FG has established those bindings.

Do we know what FG uses to determine connected input devices?

[innactpro]

As an experiment inspired by multiple mice in Linux, TrackBall.xml was created in /Input/Event/ELECOM. However, FG did not like that as it caused 'Fatal Exception std::exception' and failed to launch, even if the trackball was disabled with xinput.

Deleting the TrackBall.xml allowed FG to open as usual. This suggests a conflict within FG seeing the trackball as the mouse input then again as an event xml.

So this didn't work.

[innactpro]

And connecting a second mouse, then following the Multiple mice on Linux section of the Wiki's Input device page also returns the std::exception and will not load FG.

Removing the MouseExtra.xml does not cause a 'Fatal exception' and FG loads as usual. Which means it was not a conflict in FG having the trackball as the mouse and as an event xml.

Perhaps something has changed effecting the use of multiple mice on Linux? Some of the xinput information seems outdated in the Multiple mice on Linux section. Perhaps implementing multiple mice needs updating as well?

[polly]

" But you're not helping, why is that ? "

I have no idea what trackball.xml contains, nor what you put in Mousextra.xml, nor what
'also returns the std::exception and will not load FG.'
or
'Removing the MouseExtra.xml does not cause a 'Fatal exception' ' actually mean.

I went to the wiki page with cdgae's instructions linked in the other thread,
connected a USB optical mouse
I used dmesg to find the second mouse was named 'USB Optical Mouse'
I copied this name into the MouseExtra.xml file, which I copied into fgdata/Input/Events
I made a udev rule as instructed on the wiki page and rebooted.
Flightgear loads fine for me and either mouse operates controls in the cockpit

I'd suggest, if you have two conventional mouses, use them to confirm the wiki instructions work for you, they absolutely work OK here.

Duckduck search "elecom huge trackball linux" there seem plenty of hints on what's needed
for the device under linux, I noticed some comments that button map in unexpected ways.

Once you are satisfied the trackball is working through the input layers in Linux, use the property tree in flightgear to see if your button assignments are getting to flightgear's bindings.

Since I don't have a trackball I can only guess and suggest, it saves my time, too, if you help by showing details of what you are doing.

[innactpro]

" But you're not helping, why is that ? "

I have no idea what trackball.xml contains, nor what you put in Mousextra.xml, nor what
'also returns the std::exception and will not load FG.'
or
'Removing the MouseExtra.xml does not cause a 'Fatal exception' ' actually mean.

So, both the TrackBall.xml and MouseExtra.xml contained the example xml code from the wiki with the name changed to the trackball name or the mouse name as reported in xinput list. The TrackBall.xml was used with the trackball, which seemed a good way to organized which attempt was which, and the MouseExtra.xml was used with the mouse. With either of these xml files in the Event folder, when launching FG a little window would appear stating 'Fatal exception std::exception' with a button labeled 'OK'. Clicking 'OK' would close both the window and FG which would not complete loading. Only one of the xml files was in the Event folder at a time. Once the xml files were deleted from the Event folder, FG worked properly. My computer is running Ubuntu, not Devuan, so no udev rule was created. Outside FG the trackball and all buttons function properly.

With the udev rule being the only difference in our two situations, that may be the key. Give me some time to investigate and report back.

[innactpro]

Creating the udev rule copied and pasted from the wiki then after rebooting disabling the second mouse through xinput still results in 'Fatal exception std::exception' and FG does not launch.

And again, deleting the MouseExtra.xml allows FG to launch normally with 90-fgmouseextra.rules still in /rules.d.

[wkitty42]

perhaps increasing your logging to debug (or bulk) may help? maybe the offending task will be logged before the exit...

add one of the following to your command line or launcher Additional Settings section...

Code: Select all

--log-level=debug

OR

Code: Select all

--log-level=bulk

you may also be headed into gdb territory to run FG in to see what's going on under the hood...
please also clarify which version of FG you are running, just to be sure...

[innactpro]

Version 2020.3.18

And '--log-level=debug' was added to Additional Settings.

What might be the location of the log and what info would be most useful from the log? Home/.fgfs includes several logs, or would there be a different location?

[wkitty42]

Version 2020.3.18

thanks...

Home/.fgfs includes several logs, or would there be a different location?

that's the proper location of the log in question... the most recent one does not have a number in the name... the older ones start with zero and go up to 10 with 10 being the oldest of the 12 available...