Opened 13 years ago

Closed 13 years ago

Last modified 13 years ago

#4658 closed enhancement (fixed)

Lirc Improvment

Reported by: xavier Owned by: Isaac Richards
Priority: minor Milestone: unknown
Component: mythtv Version: head
Severity: medium Keywords: lirc keybinding libmythui
Cc: Ticket locked: no



I am trying to improve lirc support in myth: My goal is :

  • to be able to configure lirc without simulating QKeyEvent
  • To get ride of the .lircrc and use the socket which should make easier to configure (without restarting mythtv)
  • to be able to program each remote control differently (as long as their are not the same make)
  • Potentially each Input would be configurable individually

This patch is just a draft. I implement the MythInputEvent? as well as the child class MythLircEvent? (future class could be MythKeyEvent?,MythKeyExternalEvent?...) I create the inputEvent method only in mythmenuthemed as a example.

If well written, this patch could also make MythMainWindow? unaware of the different kinds of InputEvent? (remove some ifdef ...).

If adopted, Widget would have to use inputEvent methods to handle it and get rid of the keyPressEvent

I still need :

  • to create the MythKeyEvent? (which will encapsulate a QKeyEvent) and redirect the main keyPressEvent to inputEvent
  • make the jump work the same way
  • replace my dirty mapping in keyContext by something else

I am facing few problem also:

  • I am not to sure how to manage the retro compatibility, maybe by using the old way if a .lircrc file is found ?
  • To make this work, I have to replace all keyPressEvent method by inputEvent, And there is quite a lot :). Any idea to allow some kind of cohabitation?

Is there a chance that such patch would be applied (when it will be finished and clean of course) or do I waste my time?

The bz2 contain the diff file, the mythinputevent file and an example of keybindings table

I did change my keybinding table too:

  • add a column input which should include 'keyboard', 'lirc' as retrieved by MythInputEvent::getInputName
  • replace the primary key on context,action,hostname by context,action,hostname,input

I wonder if this primary key is a good idea as we could have a primary key as context,action,hostname,input,keylist and have only on bindings per row (in keylist i mean). The present modele us QKeySequence which have a limitation of 4 QKeyEvent, I don't this this limitation is a good idea. To have only on key per keylist would simplify the parsing too.

No change have been done in MythControl? neither, Is there any reason to have MythControl? as a plugin ? Would be better to have this in the core, Each plugin/dialog/context could be configurable from their menu (may be in the help page). it make more sense for the user point of view and it would be also easier to bind a missing key quickly without quiting what the user is doing.

Any review, suggestion would be a great help.

Regards, Xavier

Attachments (1)

lircimprovment.bz2 (6.1 KB) - added by xavier 13 years ago.
diff and keybinding exampl

Download all attachments as: .zip

Change History (4)

Changed 13 years ago by xavier

Attachment: lircimprovment.bz2 added

diff and keybinding exampl

comment:1 Changed 13 years ago by stuartm

Resolution: duplicate
Status: newclosed
Version: unknownhead

This is a duplicate of #2239, could you post patches and descriptions there?

This is a pretty old idea, we've seen many patches to do the same thing. Not all of them were done in a way that we would accept, but mostly although the general idea is good no devs have had time to look at the issue.

comment:2 Changed 13 years ago by danielk

Resolution: duplicatefixed

(In [16266]) Fixes #4658. Fixes a segfault in videoout_null.

This just copies over some of the locking we use in VideoOutputXv? and cleans up the ctor/dtor.

comment:3 Changed 13 years ago by danielk

shoot [16266] should have referenced #4758.

Note: See TracTickets for help on using tickets.