Round 17 projects

Previous projects, from round 16 are available here.

Adding support for stateless codecs in the Virtual Codec Driver (vicodec)

The kernel abstracts the underlying hardware to userspace through APIs (system calls). To access any kind of hardware, be it a touch pad, a monitor, the ram memory, the disk, the network card or the webcam, applications perfom system calls using an API or protocols specified by the corresponding subsystem.

The video codec API is a relatively recent addition to the kernel, it is an extension of the video4linux2 API and it is maintained by the kernel Media subsystem team. If your computer has a hardware video codec, then the video codec API exposes this hardware to userspace, allowing your operating system to use hardware acceleration to encode a video (convert it from a raw frame format such as RGB, to a compressed format such as MPEG or H.264) or to decode it.

The Virtual Codec Driver (vicodec) emulates codec hardware. This is useful for developers who do not have codec hardware available to test their application in userspace and want to be sure their code would work with a real codec. Then, instead of buying real hardware, the developer could just use the vicodec driver to emulate one.

Besides that, virtual drivers are important for testing the video4linux framework and the API in case of regressions. They are also very useful to prototype new API extensions.

There are two types of codecs: stateful and stateless.

From https://lkml.org/lkml/2018/7/24/537 (but generalizing to codecs):

A stateless codec is a codec that works without retaining any kind of state in the hardware between processing frames. This means that when each frame is encoded/decoded the client (userspace) is responsible for maintaining the encoding/decoding state and providing it to the driver. This is in contrast to the stateful video codec interface, where the hardware maintains the encoding/decoding state and all the client has to do is to provide the raw or compressed stream.

The vicodec driver currently emulates the codec through the stateful API, but the support for stateless codecs is still missing. The main goal of this project is to add support for the stateless FWHT codec in vicodec and also improve v4l2 testing tools.

The stateful codec specification is expected to be finalized by the time this project starts, but it is unlikely that the vicodec driver will comply fully to that specification. The intern is expected to start by finishing the stateful codec part of vicodec. This is needed for the stateless codec implementation as well, so this is a good place to start anyway.

Mentor:: Helen Koike and Hans Verkuil

Dri-devel aka kernel GPU subsystem (2 internships)

In laptops, tablets, phones and lots of other places GPU/display uses more silicon die space than everything else combined (humans are mostly visual people after all), dri-devel (and the wider set of projects under the X.org Foundation's umbrella) is the community that makes this all work and shine.

We have a bunch of janitorial-type projects collected in https://dri.freedesktop.org/docs/drm/gpu/todo.html, varying from fairly mechanical to really challenging. We're also taking the usual array of checkpatch and coccinelle driven cleanup patches (they're great newbie starter patches). For an internship this means there's a lot of "build your own internship program", and we're definitely open to other projects. Just chat with mentors to start scoping a good project and what might be interesting for you.

Bit more PR for dri-devel: We're the subsystem that implemented the new shiny kernel-doc tooling and pushed for the conversion https://dri.freedesktop.org/docs/drm/gpu/index.html. We're the first ever kernel subsystem with a real CoC (and yes it's enforced) https://dri.freedesktop.org/docs/drm/gpu/introduction.html#code-of-conduct. We're running our main trees with a much more participative model where all regular contributors have direct commit rights to relevant repos (instead of having to always jump through maintainers to get anything landed) https://blog.ffwll.ch/2016/09/commit-rights-in-the-linux-kernel.html. In short, we take newbie's and our contributor's needs in general very serious and try to care for them.

Best place to say hi to the community is by joining #dri-devel on freenode. You need a registered nick: https://freenode.net/kb/answer/registration

Mentor:: Daniel Vetter , Rodrigo Siqueira , Harry Wentland and Manasi Navare

Enhance graphic experiences for Linux VMs on Hyper-V

To run Linux guests on Hyper-V, the hypervisor from Microsoft, we have a set of drivers to enhance the performance of storage, network, and graphics, etc. We will work together with the intern student to get familiar with the driver design, and submission process to Linux community. This project will also have a focus on enhancing the frame buffer, hyperv_fb driver, for graphic experiences. For example, to reduce the overhead when screen area is being updated, improve tuning capability for end users. Other drivers may also be worked on for the mutual interest of the intern and our [Microsoft's] team.

Mentor:: Haiyang Zhang

Improve Linux kernel support for running as a guest on the Hyper-V hypervisor (2 internships)

Improve the core Linux kernel support for running as a guest on Microsoft’s Hyper-V hypervisor, as well as the Hyper-V specific device drivers for the VMbus and related synthetic devices. The work includes some bug fixing to get started and then moves on to more substantial enhancements to improve performance and functionality.

Mentor:: Sasha Levin , Long Li and Michael Kelley