2 Copyright 2020 Chris Tallon
4 This file is part of VOMP.
6 VOMP is free software; you can redistribute it and/or modify
7 it under the terms of the GNU General Public License as published by
8 the Free Software Foundation; either version 2 of the License, or
9 (at your option) any later version.
11 VOMP is distributed in the hope that it will be useful,
12 but WITHOUT ANY WARRANTY; without even the implied warranty of
13 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
14 GNU General Public License for more details.
16 You should have received a copy of the GNU General Public License
17 along with VOMP. If not, see <https://www.gnu.org/licenses/>.
26 The old design had an abstract Remote class with a single Remote* (RemoteWin, RemoteLinux, RemoteLirc)
31 A single RemoteMan object will look after several Input devices. RemoteMan will have getInstance().
33 An abstract Input class (old Remote) defines common stuff about input devices.
35 Many Input* objects may exist at the same time. They will be:
43 Obviously Linux and Win won't be active simultaneously. UDP will roll in the UDP button receiver
44 into this input system.
46 The old design grew out of the fact the main thread waited on Remote::getButtonPress. Now the main
47 thread waits on the MessageQueue. The input system should be separate, run in its own threads and
48 should insert messages to the queue on input.
52 It would be nice if the input system could boot up in its own time, not delaying the rest of the
53 program, but this may not be achievable.
55 In the future it will be possible to implement hot plugging of USB input devices. (Currently vomp
56 only uses what is present at vomp-startup).
58 The CEC code can be removed from InputLinux. Under the new design they are nothing to do with
61 Direct Lirc input can be brought back - probably very easily. TODO
63 Input objects can be easily and individually enabled / disabled.
65 New types of input can be implemented much easier.
67 For now, two decisions to make things a bit easier:
69 1. InputMan will hardcode knowledge about the Input types with hard pointers to each. In future
70 perhaps this will change to a dynamic list of Input objects where InputMan refers to them
71 through the Input interface only.
73 2. InputLinux will continue to represent all devices found in /dev/input. If there is a good
74 reason in future then this should switch to several InputLinux objects representing one
82 #include "abstractoption.h"
90 class InputMan: public AbstractOption
95 static InputMan* getInstance();
100 bool start(); // MessageQueue should be ready before this is called
101 void stop(); // Nothing should be sent to MQ after this
103 bool mayHaveFewButtons();
105 bool handlesVolume(); // Returns true if we have an InputCEC willing to handle volume
109 void changePowerState(bool powerOn);
111 // Abstract Option interface
112 bool addOptionPagesToWTB(WTabBar* wtb);
113 bool addOptionsToPanes(int panenumber, Options* options, WOptionPane* pane);
114 bool saveOptionstoServer();
116 static const char* getVompKeyName(UCHAR vompKey);
118 std::string getHardCodedHardwareKeyNamesForVompKey(UCHAR vompKey);
119 std::string getAllHardwareKeyNamesAssignedToVompKey(UCHAR vompKey);
122 static InputMan* instance;
124 InputLinux* inputLinux{};
125 InputCEC* inputCEC{};
126 InputWin* inputWin{};
127 InputUDP* inputUDP{};
128 InputLirc* inputLirc{};
136 // don't have Input inherit AbstractOption, just individual inputs. Then one day could test with
137 // dynamic_cast whether to call the AO IF stuff on them
138 // could also have a CEC IF and do the same?