Re: [RFC] What are the goals for the architecture of an in-kernel IR system?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, Nov 28, 2009 at 2:55 PM, Krzysztof Halasa <khc@xxxxxxxxx> wrote:
> Jon Smirl <jonsmirl@xxxxxxxxx> writes:
>
>> EVIOCSKEYCODE is lacking, first parameter is an INT. Some decoded IR
>> codes are over 32b. Christoph posted an example that needs 128b.
>
> This only means that the existing interface is limited.
>
>> This
>> is a problem with ioctls, they change size depending on platform and
>> endianess.
>
> But not this: you can use fixed-width u16, u32, u64 and e.g. u8[x].
> I don't know an arch which changes int sizes depending on endianness,
> is there any?

Endianess comes into play when send/receiving multibyte integers on
platforms with different endianess.  That where the hton() stuff comes
from. IOCTLs obviously work, you just have to allow for all of this
stuff when writing them.

http://linux.die.net/man/3/htonl


> 32/64 binary compatibility needs some minimal effort.
> --
> Krzysztof Halasa
>



-- 
Jon Smirl
jonsmirl@xxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux