Page 2 of 4 FirstFirst 1234 LastLast
Results 11 to 20 of 32

Thread: Fintek MCEUSB Mythbuntu 12.04.02

  1. #11
    Join Date
    Nov 2006
    Beans
    217

    Re: Fintek MCEUSB Mythbuntu 12.04.02

    Found this comment on http://www.lirc.org/faq.html

    "From 2.6.36 on all LIRC kernel drivers are already included in the kernel. There has been a slight interface change in the LIRC ioctls that will affect 64-bit kernels. For recent kernels please only use 0.9.0 which is compatilbe with the in-kernel drivers."
    Since I was trying to get the HP/Fintek device to work on a 64 bit Ubuntu 13.04, maybe I should try again using 32 bit...
    CPU: 80286 @ 10Mhz; FPU: n/a; RAM: 256K, HD: 20 Meg
    Graphics: Monochrome; Power Supply: 100 W; Case: Yes/Open

  2. #12
    Join Date
    Mar 2008
    Beans
    14

    Re: Fintek MCEUSB Mythbuntu 12.04.02

    Quote Originally Posted by billstei View Post
    Found this comment on http://www.lirc.org/faq.html



    Since I was trying to get the HP/Fintek device to work on a 64 bit Ubuntu 13.04, maybe I should try again using 32 bit...
    I tried 10.04 same problem let me know if the 32bit works.

  3. #13
    Join Date
    Nov 2006
    Beans
    217

    Re: Fintek MCEUSB Mythbuntu 12.04.02

    Unfortunately the 32 bit Ubuntu 13.04 Beta 2 does not pass the integrity check (or run the Ubuntu Installer), and this problem is being tracked here:

    Ubuntu 13.04 32-bit Live Broken

    In the meantime I thought it would be advantageous to try getting better debug information from the mceusb kernel module by compiling my own as detailed here:

    Compile mceusb.c

    In order to get the debug info turned on, instead of just using "make", I did this:

    make CONFIG_USB_DEBUG=1

    In theory the mceusb.c file is version 1.92 (line 48 of mceusb.c) in both Ubuntu 12.10 and 13.04 Beta 2+ (amd64) however, running a diff shows that there have been several changes to the code, any one of which could have produced problems/bugs (and going further back to Ubuntu 12.04 etc might have even more changes). In any event, I am very new to this code, but it seems relatively easy to turn on the debugging messages - see lines 157-168, C macro mce_dbg() -- including the ability to add my own...

    I am initially suspicious of the following code (circa line 1355):

    if (ir->flags.microsoft_gen1)
    mceusb_gen1_init(ir);
    else if (!is_gen3)
    mceusb_gen2_init(ir);

    Is the Fintek a Gen1, Gen2, or Gen3, MCE USB device? (and did the mceusb module get it right...)
    CPU: 80286 @ 10Mhz; FPU: n/a; RAM: 256K, HD: 20 Meg
    Graphics: Monochrome; Power Supply: 100 W; Case: Yes/Open

  4. #14
    Join Date
    Mar 2008
    Beans
    14

    Re: Fintek MCEUSB Mythbuntu 12.04.02

    Pretty sure gen 2. Gen 1 will not work in win 7.
    Last edited by betolley; April 10th, 2013 at 06:52 PM.

  5. #15
    Join Date
    Nov 2006
    Beans
    217

    Re: Fintek MCEUSB Mythbuntu 12.04.02

    I have a "working" mceusb.ko now with debugging turned on. Disregard my "make CONFIG_USB_DEBUG" invocation example above, that does not work. I put a #define CONFIG_USB_DEBUG right before the debug vaiable #ifdef instead.

    The driver thinks the Fintek is Gen2 -- I take it there is no such thing as a Gen3.

    Here is the dmesg output when unloading (rmmod) and reloading (modprobe) the module, twice: Debug Info via dmesg

    Interesting things:

    1) The error message: Illegal PORT_SYS command
    2) The error messages: Unknown command 0x9f 0x05, Unknown command 0x00 0x02, Unknown command 0x00 0xff
    3a) 1st rmmod/modprobe message: 0 tx ports (0x0 cabled) and 2 rx sensors (0x1 active)
    3b) 2nd rmmod/modprobe message: 2 tx ports (0x0 cabled) and 2 rx sensors (0x0 active)

    It seems obvious that 3a/3b would not give me a warm fuzzy feeling since nothing changed or was utilized between the 10105 and 10146 timestamps.
    CPU: 80286 @ 10Mhz; FPU: n/a; RAM: 256K, HD: 20 Meg
    Graphics: Monochrome; Power Supply: 100 W; Case: Yes/Open

  6. #16
    Join Date
    Mar 2008
    Beans
    14

    Re: Fintek MCEUSB Mythbuntu 12.04.02

    Do you have a working blaster driver now or just a compiled one?

  7. #17
    Join Date
    Nov 2006
    Beans
    217

    Re: Fintek MCEUSB Mythbuntu 12.04.02

    "Working" meaning not working, just dmesg noisier. What do you get when you do:

    dmesg | grep "tx ports"

    Keep in mind that I really have no idea what I'm doing (yet)... but maybe the question we need to ask is what does "cabled" mean here:

    mceusb 6-2:1.0: 2 tx ports (0x0 cabled) and 2 rx sensors (0x0 active)

    My first guess: It means the driver thinks there are 2 transmit ports available (probably true) and 0 of them have IR blasters plugged into them (not true).
    CPU: 80286 @ 10Mhz; FPU: n/a; RAM: 256K, HD: 20 Meg
    Graphics: Monochrome; Power Supply: 100 W; Case: Yes/Open

  8. #18
    Join Date
    Nov 2006
    Beans
    217

    Re: Fintek MCEUSB Mythbuntu 12.04.02

    Some further debugging info:

    In the dmesg log in my Comment #15 above there is the following:

    [10105.665865] mceusb 6-2:1.0: Get carrier mode and freq
    [10105.666855] mceusb 6-2:1.0: rx data: 9f 06 01 66 (length=4)
    [10105.666861] mceusb 6-2:1.0: Got carrier of 24390 Hz (period 41us)

    Decoding the message:

    9f = CMD_PORT_IR (Command: Port IR)
    06 = CMD_SETIRCFS (Command: Set IR Carrier Frequency)
    01 = CP (Carrier Prescalar)
    66 = CC (Carrier Period)

    Period = ( 2 ^ (CP*2) ) * (CC+1) * 0.1 uS
    Frequency = 1 / Period

    This is documented in "Windows-Media-Center-RC-IR-Collection-Green-Button-Specification-03-08-2011-V2.pdf" (pgs 87-88) but don't ask me how to point/link to it on microsoft.com... try Google.

    Since the values above are in hex we have:

    Period = ( 2 ^ (1*2) ) * (102+1) * 0.1 uS = 41.2 uS
    Frequency = 1 / 41.2 uS * (1000000 uSec / 1 Sec) = 24272 Hz

    And that agrees with the "Got carrier..." response from the MCEUSB device, however... on Page 88 of the specification we have:

    "The following table describes CP and CC values for periods from 16 μsec to 34 μsec. This covers the required range of 30 to 60 KHz. Initial values of CP and CC should be 1 and 66 (37037 Hz), respectively."
    And a carrier frequency of 37 Khz would be more "normal"/default for an IR remote (~36 Khz typically, yes?), but in order to get that frequency we need 66 decimal, not 0x66 hex (which is 102).

    So, is this a bug, or just a big misunderstanding? I'm going to guess that the device did not power-up/boot at 24 Khz. And I'm going to guess that the Pace DC50X/Motorola DTA100 won't listen to anything at that frequency (?).
    Last edited by billstei; April 11th, 2013 at 04:10 PM.
    CPU: 80286 @ 10Mhz; FPU: n/a; RAM: 256K, HD: 20 Meg
    Graphics: Monochrome; Power Supply: 100 W; Case: Yes/Open

  9. #19
    Join Date
    Nov 2006
    Beans
    217

    Re: Fintek MCEUSB Mythbuntu 12.04.02

    This doesn't fix the problem, but is a legitimate bug, and affects the debug messages for anyone trying to figure this out -- add the following line:

    case MCE_RSP_EQIRNUMPORTS:

    immediately after this switch case grouping (circa line #505 in mceusb.c):

    case MCE_CMD_PORT_IR:
    switch (subcmd) {
    case MCE_CMD_UNKNOWN:
    case MCE_RSP_EQIRCFS:
    case MCE_RSP_EQIRTIMEOUT:
    case MCE_RSP_EQIRRXCFCNT:

    Fixes wrongly reported MCE_RSP_EQIRNUMPORTS rx data/length of 2, should be 4

    Edit: Just to clarify, the datasize = 2; line is correct because it adds that to the Command and Sub-command bytes. The problem was the default is datasize = 0, and 2 + 0 = 2 (wrong total length for MCE_RSP_EQIRNUMPORTS), should be 2 + 2 = 4.
    Last edited by billstei; April 11th, 2013 at 09:54 PM.
    CPU: 80286 @ 10Mhz; FPU: n/a; RAM: 256K, HD: 20 Meg
    Graphics: Monochrome; Power Supply: 100 W; Case: Yes/Open

  10. #20
    Join Date
    Nov 2006
    Beans
    217

    Re: Fintek MCEUSB Mythbuntu 12.04.02

    Around line #461 in mceusb.c there is this definition:

    static char DEVICE_RESUME[] = {MCE_CMD_NULL, MCE_CMD_PORT_SYS,
    MCE_CMD_RESUME};

    which would produce a three byte message: 0x00 0xFF 0xAA

    Again referring to the documentation (see Comment #18 above), page 88 defining the CMD_RESUME, it should be:

    static char DEVICE_RESUME[] = {MCE_CMD_PORT_SYS, MCE_CMD_RESUME};

    which would produce a two byte message: 0xFF 0xAA

    This problem can be seen in my previous dmesg output (Comment #15 above) as:

    92. [10146.244473] mceusb 6-2:1.0: tx data: 00 ff aa (length=3)

    followed by:

    98. [10146.261440] mceusb 6-2:1.0: rx data: 00 ff (length=2)
    99. [10146.261445] mceusb 6-2:1.0: Unknown command 0x00 0xff

    Fixing this makes dmesg a whole lot more exciting, like something started working, but I am not an expert, and I have not tried blasting yet...
    CPU: 80286 @ 10Mhz; FPU: n/a; RAM: 256K, HD: 20 Meg
    Graphics: Monochrome; Power Supply: 100 W; Case: Yes/Open

Page 2 of 4 FirstFirst 1234 LastLast

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •