Le 01/05/18 à 17:09, Dan Williams a écrit :
> Quoting Mark's original RFC:
>
> "Recently, Google Project Zero discovered several classes of attack
> against speculative execution. One of these, known as variant-1, allows
> explicit bounds checks to be bypassed under speculation, providing an
> arb
On Monday 08 October 2012 17:49:00 Hans Verkuil wrote:
> On Mon October 8 2012 17:06:20 Florian Fainelli wrote:
> > Hi Hans,
> >
> > On Thursday 27 September 2012 16:33:30 Hans Verkuil wrote:
> > > Hi all,
> > >
> > > During the Linux Plum
Hi Hans,
On Thursday 27 September 2012 16:33:30 Hans Verkuil wrote:
> Hi all,
>
> During the Linux Plumbers Conference we (i.e. V4L2 and DRM developers) had a
> discussion on how to handle the CEC protocol that's part of the HDMI
standard.
>
> The decision was made to create a CEC bus with CEC
me because it means we have to know about the CEC protocol itself.
I fear that if we start doing this with the CEC UI codes, we end-up doing the
same for the system-related messages (Power, standby etc ...) and this is also
to be avoided.
>
> Best Regards,
> Murali
> From: Florian
ode.google.com/p/cec-arduino/wiki/ElectricalInterface
Having an AVR with v-usb code and cec code doesn't look all that hard
nor impossible, so one could simply have a USB plug on one end, and an
HDMI plug on the other end, utilizing only the CEC pins.
This would make it more something like LIRC if
Hi Hans, Martin,
Sorry to jump in so late in the HDMI-CEC discussion, here are some
comments from my perspective on your proposal:
- the HDMI-CEC implementation deserves its own bus and class of devices
because by definition it is a physical bus, which is even electrically
independant from t
Hello,
On 12/03/11 01:37, HoP wrote:
Hi Alan.
2011/12/3 Alan Cox:
On Thu, 1 Dec 2011 15:58:41 +0100
HoP wrote:
Hi,
let me ask you some details of your interesting idea (how to
achieve the same functionality as with vtunerc driver):
[...]
The driver, as proposed, is not really a driver,
