[GiGaBlue QUAD] Delay on keys with longpress functions (Zeus)

[ronaldex]

After installing the new Zeus release on my GB Quad and it felt slower then then 3.0 version.

I've noticed there have been added some longpress functionalities to the (channel) up/down buttons. These longpress actions (logically) add a delay to the buttons which makes the reciever feel slow in reacting on normal keypresses. I normally use a Harmony remote, but the original remote seems to have the same problems.

Features on longpresses can be a nice addition, but I don't think they should interfere with the receivers basic functionalities (viewing tv, zapping, navigating the channel- / bouqet-list).

I've changed the values in keymap.xml and the reciever is reacting as it should again. I prefer a fast channel switching and navigation to things like PiP zap any day.

 

[skippie]

I got the same delay with my quad.
Where can I find keymap.xml and what did you change?

sent from Pipo M9 Pro

 

[ronaldex]

The file:
/usr/share/enigma2/keymap.xml

Changes:

	<map context="InfobarChannelSelection">
		<key id="KEY_LEFT" mapto="LeftPressed" flags="mr" />
		<key id="KEY_RIGHT" mapto="RightPressed" flags="mr" />
		<key id="KEY_UP" mapto="switchChannelUp" flags="m" />
		<key id="KEY_DOWN" mapto="switchChannelDown" flags="m" />
		<!--
		<key id="KEY_UP" mapto="switchChannelUpLong" flags="l" />
		<key id="KEY_DOWN" mapto="switchChannelDownLong" flags="l" />
		-->
		<key id="KEY_PREVIOUS" mapto="historyBack" flags="mr" />
		<key id="KEY_NEXT" mapto="historyNext" flags="mr" />
		<key id="KEY_BACK" mapto="historyBack" flags="mr" />
		<key id="KEY_FORWARD" mapto="historyNext" flags="mr" />
		<key id="KEY_CHANNELUP" mapto="ChannelPlusPressed" flags="m" />
		<key id="KEY_CHANNELDOWN" mapto="ChannelMinusPressed" flags="m" />
		<!--
		<key id="KEY_CHANNELUP" mapto="ChannelPlusPressedLong" flags="l" />
		<key id="KEY_CHANNELDOWN" mapto="ChannelMinusPressedLong" flags="l" />
		-->
		<key id="BTN_0" mapto="zapUp" flags="mr" />
		<key id="BTN_1" mapto="zapDown" flags="mr" />
		<key id="KEY_SAT" mapto="openSatellites" flags="m" />
	</map>

 

[skippie]

thanks

sent from Pipo M9 Pro

 

[andyblac]

remember changing this file will get reverted on every update.

why not just let go of the button quicker ?

 

[Rob van der Does]

remember changing this file will get reverted on every update.

Exactly. Messing system-files is never a good idea (IMHO).

Anyway: what if you just use a short-press? As said before: the box reacts on letting the button go, not on pressing it.

 

[skippie]

Guys, what do you think most ppl would like :

pip-zap at cost of faster zapping or
faster zapping without pip-zap?

letting the button go quicker doesn't make it faster zapping.

I liked my fast-zapping quad, not this way.
It's just copying over the keymap.xml time after time, I guess.

sent from Pipo M9 Pro

 

[Rob van der Does]

I don't have a quad, but on the boxes I do have there's no slower zapping then before.

 

[d_f]

I 100% agree with skippie, I rarely use pip and have no use for the long press, and pressing it quickly does not make it quicker. Please give us the option to turn it off, otherwise we will have to overwrite the key map.xml after every update. My Quad is a lot quicker now the keymap file has been amended.

 

[GAH2402]

Hi,

Pointed out the exact same issue yesterday, and just to confirm, releasing the button quicker makes no difference at all.

http://www.world-of-satellite.com/s...light-delay-on-calling-up-Bouquet-List-(Zeus)

GAH

 

[ronaldex]

I'm aware that changes will be lost after an update, but it's the only way of 'fixing' it for now (for me at least).

Like stated above, short-pressing a button doesn't help, there is a delay of ca. 1 sec for all buttons with long-press functions (on my gigablue quad).

 

[andyblac]

then is an issue with drivers. how long delay is it ?

 

[andyblac]

short-pressing a button doesn't help, there is a delay of ca. 1 sec for all buttons with long-press functions (on my gigablue quad).

then def a driver issue, no such delay on ET's, VU's etc.

 

[skippie]

This driver issue problem we didn't have with 3.0

Sent from my GT-I9300 using Tapatalk

 

[pooface]

This driver issue problem we didn't have with 3.0

Sent from my GT-I9300 using Tapatalk

And did you update the drivers to the latest in the older 3.0 build??? Or, was it using the older drivers, so a bug could've been introduced with newer drivers?

Personally haven't got a gb machine myself, so don't know. But the vu/et I've tested haven't shown these issues...

 

[skippie]

With all drivers we didn't have this issue

Sent from my GT-I9300 using Tapatalk

 

[huve]

I went back to 808, because of slow button response and I don't have time at the moment to make all my settings to Zeus.

 

[ronaldex]

I didn't have time to test with vix 3.0 yet, but I think the issue was already present.

It just wasn't as noticable because of the type of keys that had key-release / long-press actions (color-keys instead of main-navigation / ch- / ch+).

 

[skippie]

I didn't have this problem at all with 3.0

sent from Pipo M9 Pro

 

[wangled592]

yea slow here to ,back to 808 :-(