Jump to content
Flirc Forums


  • Content count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About phlurker

  • Rank
    Curious Flirc-er
  1. hi, i just updated to the 2.3.9 package and noticed an extra generic man page being included in /usr/share/doc/flirc/Flirc.1. please see attached image of the formatted/rendered man page. seems a generic bit unintentionally included in the package. thanks, -matt
  2. phlurker

    flirc_1.3.0-1_amd64.deb segfault

    yep it launches fine now, thanks. and yes, the fonts are funny :D
  3. phlurker

    inter-key delay being ignored?

    *(&@$(&ing harmony :angry: hehe
  4. phlurker

    inter-key delay being ignored?

    hey, 3.3 is 100% better with the record_api keys repeating, thanks. about the inter-key delay - is my understanding correct, though? is the harmony ignoring the setting?
  5. phlurker

    inter-key delay being ignored?

    :-) any progress with the segfaults on amd64?
  6. hi, i've got a harmony 700. i'm seeing repeated keypresses being emitted at the slightest touch of (especially) the red/green/yellow/blue buttons. i've programmed these particular keys to be alt+z, alt+x, alt+c, alt+v. even after setting repeats to zero (in harmony), setting inter-key delay to 1000ms on the harmony, and setting inter-key delay to 7 on the flirc, i am still having this issue. what is very odd to me is that holding a key will emit about 10 repeats a second. if i understand what inter-key delay is supposed to do, a setting of 1000ms should only emit 1 keypress a second at a maximum. but i'm still seeing about 10/s emitted. so it seems like this setting is being ignored. does that sound right? strangely, although regular keys also repeat quickly, as if they ignore inter-key delay, they don't emit multiple keypress events at the slightest touch like the ones configured with record_api do. another thing i've noticed is that since recording them with flirc_util record_api, i can't delete them (they don't appear in the output of 'settings'), and i can't re-record them using the standard 'record' command (it says key already in use). so i'm unable to test if the hair-trigger nature of the red/green/yellow/red keys is a result of using record_api, or there is something else going on (at least without formatting and losing *all* of my settings). in conclusion, either i'm misunderstanding inter-key delay in thinking that it will rate-limit key repeats proportional to the specified delay, or inter-key delay is horribly broken somewhere. and, i am unable to re-record keys as non-modifier keys that were previously recorded with record_api, nor am i able to delete them using flirc_util. p.s. this is on firmware 3.0 / flirc_util 1.2.7
  7. phlurker

    flirc_1.3.0-1_amd64.deb segfault

    hi, on ubuntu 14.10 amd64, the Flirc gui (from flirc_1.3.0-1_amd64.deb) immediately segfaults and doesn't open. here is a backtrace, if you have an unstripped binary (preferably compiled with -ggdb3) i can get you info for that as well. Thread 1 (Thread 0x30b901428c0 (LWP 3172)): #0 0x000000000058c3b0 in ?? () #1 0x0000030b8efb240d in ?? () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4 #2 0x0000030b8efb2805 in ?? () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4 #3 0x0000030b8c0f0b28 in _SmcProcessMessage () from /usr/lib/x86_64-linux-gnu/libSM.so.6 #4 0x0000030b8bee2167 in IceProcessMessages () from /usr/lib/x86_64-linux-gnu/libICE.so.6 #5 0x0000030b8e232a7a in QMetaObject::activate(QObject*, QMetaObject const*, int, void**) () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4 #6 0x0000030b8e27d02e in QSocketNotifier::activated(int) () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4 #7 0x0000030b8e23b76b in QSocketNotifier::event(QEvent*) () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4 #8 0x0000030b8ef3511c in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4 #9 0x0000030b8ef3b870 in QApplication::notify(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4 #10 0x0000030b8e21e86d in QCoreApplication::notifyInternal(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4 #11 0x0000030b8e24c61c in ?? () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4 #12 0x0000030b8cc76c5d in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #13 0x0000030b8cc76f48 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #14 0x0000030b8cc76ffc in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #15 0x0000030b8e24c031 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4 #16 0x0000030b8efd84e6 in ?? () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4 #17 0x0000030b8e21d4f1 in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4 #18 0x0000030b8e21d805 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4 #19 0x0000030b8e222f67 in QCoreApplication::exec() () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4 #20 0x0000000000411f32 in ?? () #21 0x0000030b8d7e2ec5 in __libc_start_main (main=0x411e66, argc=1, argv=0x380ef672658, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x380ef672648) at libc-start.c:287 #22 0x000000000040f80f in ?? ()