As far i can see the fix in vix is that you can configure the one and only input resource... So it is depending on this config a keyboard works correctly or a normal remote... Both together is a nogo...
For other boxes this doesn't care.
Kep mapping issue Qwerty keyboard on OpenPli 4.0
Started by guitarman, 16 Dec 2013 13:22
26 replies to this topic
Re: Kep mapping issue Qwerty keyboard on OpenPli 4.0 #21
-
- PLi® Core member
- 56,376 posts
+692
Excellent
Posted 21 December 2013 - 10:30
WaveFrontier 28.2E | 23.5E | 19.2E | 16E | 13E | 10/9E | 7E | 5E | 1W | 4/5W | 15W
Re: Kep mapping issue Qwerty keyboard on OpenPli 4.0 #22
-
- Senior Member
- 7,766 posts
+184
Excellent
Posted 21 December 2013 - 11:22
As I said: we don't live in an ideal world. That applies to the worked-around world as well.
But as this setting can be changed on the fly, users won't have a (big) problem with it.
Re: Kep mapping issue Qwerty keyboard on OpenPli 4.0 #23
-
- PLi® Core member
- 2,345 posts
+121
Excellent
Posted 21 December 2013 - 15:03
I would like in the discussion to put our 10 cents.
I remember that one of the team said, adding workaround for the VU + remote is as a bullet in his heart.
If we are talking about a workaround check: http://sourceforge.n...vb/dvb.cpp#l100
Code has a lot of rows to find boxtype. Maybe I am wrong, but then we m_boxtype use only to find or box is DM7025 http://sourceforge.n...vb/dvb.cpp#l926, and then use their workaround, while for the others use another. This is likely to come from the beginnings of enigma, and then no one has paid attention to it, but if we accept this workaround, what others are worse?
Re: Kep mapping issue Qwerty keyboard on OpenPli 4.0 #24
-
- Senior Member
- 7,443 posts
+41
Good
Posted 23 December 2013 - 06:43
How about the input/event driver implementation. VU+ offers one device that reports all events, from all possible remotes. This is exactly the problem of the TS. DMM offers multiple devices, one without alpha support for the "plain" remote control and one with alpha support for the wireless keyboard. This is sense.
Anyway, I would be considering making a workaround for VU+ if there were a way to differentiate between a genuine keyboard and a VU+ "quasi"-alpha-keyboard (or any other possible not-really-alpha-keyboard). But as VU+ presents it's remote control as a "real keyboard" afaik that's not possible.
You mean we can not see the difference between the remote and an usb keyboard?
Edited by Sjaaky, 23 December 2013 - 06:46.
Re: Kep mapping issue Qwerty keyboard on OpenPli 4.0 #25
-
- PLi® Core member
- 56,376 posts
+692
Excellent
Posted 23 December 2013 - 08:04
Yep.... Vu has only one input device....
WaveFrontier 28.2E | 23.5E | 19.2E | 16E | 13E | 10/9E | 7E | 5E | 1W | 4/5W | 15W
Re: Kep mapping issue Qwerty keyboard on OpenPli 4.0 #26
-
- Senior Member
- 7,766 posts
+184
Excellent
Posted 23 December 2013 - 08:32
Not sure if it's the same, but in ViX I attached a Logitech k260 wireless mouse/keyboard (I assume that works the same as an USB keyboard) and it works fine (tested in the web-browser) while at the same time the R/C still works.
Edited by SatKiekerd, 23 December 2013 - 08:32.
Re: Kep mapping issue Qwerty keyboard on OpenPli 4.0 #27
-
- PLi® Core member
- 46,960 posts
+541
Excellent
Posted 23 December 2013 - 12:10
Maybe if they have a nice, clean solution we can adapt it.
* Wavefrontier T90 with 28E/23E/19E/13E via SCR switches 2 x 2 x 6 user bands
I don't read PM -> if you have something to ask or to report, do it in the forum so others can benefit. I don't take freelance jobs.
Ik lees geen PM -> als je iets te vragen of te melden hebt, doe het op het forum, zodat anderen er ook wat aan hebben.
1 user(s) are reading this topic
0 members, 1 guests, 0 anonymous users
