On Wed, 2011-02-09 at 02:12 -0500, Alex Deucher wrote: > On Tue, Feb 8, 2011 at 5:47 PM, Andy Walls <awalls@xxxxxxxxxxxxxxxx> wrote: > > On Tue, 2011-02-08 at 10:28 -0500, Alex Deucher wrote: > >> On Tue, Feb 8, 2011 at 4:47 AM, Hans Verkuil <hansverk@xxxxxxxxx> wrote: > >> > Just two quick notes. I'll try to do a full review this weekend. > >> > > >> > On Tuesday, February 08, 2011 10:30:22 Tomasz Stanislawski wrote: > >> >> ============== > >> >> Introduction > >> >> ============== > >> >> > >> >> The purpose of this RFC is to discuss the driver for a TV output interface > >> >> available in upcoming Samsung SoC. The HW is able to generate digital and > >> >> analog signals. Current version of the driver supports only digital output. > >> >> > >> >> Internally the driver uses videobuf2 framework, and CMA memory allocator. > >> > Not > >> >> all of them are merged by now, but I decided to post the sources to start > >> >> discussion driver's design. > > > >> > > >> > Cisco (i.e. a few colleagues and myself) are working on this. We hope to post > >> > an RFC by the end of this month. We also have a proposal for CEC support in > >> > the pipeline. > >> > >> Any reason to not use the drm kms APIs for modesetting, display > >> configuration, and hotplug support? We already have the > >> infrastructure in place for complex display configurations and > >> generating events for hotplug interrupts. It would seem to make more > >> sense to me to fix any deficiencies in the KMS APIs than to spin a new > >> API. Things like CEC would be a natural fit since a lot of desktop > >> GPUs support hdmi audio/3d/etc. and are already using kms. > >> > >> Alex > > > > I'll toss one out: lack of API documentation for driver or application > > developers to use. > > > > > > When I last looked at converting ivtvfb to use DRM, KMS, TTM, etc. (to > > possibly get rid of reliance on the ivtv X video driver > > http://dl.ivtvdriver.org/xf86-video-ivtv/ ), I found the documentation > > was really sparse. > > > > DRM had the most documentation under Documentation/DocBook/drm.tmpl, but > > the userland API wasn't fleshed out. GEM was talked about a bit in > > there as well, IIRC. > > > > TTM documentation was essentially non-existant. > > > > I can't find any KMS documentation either. > > > > I recall having to read much of the drm code, and having to look at the > > radeon driver, just to tease out what the DRM ioctls needed to do. > > > > Am I missing a Documentation source for the APIs? > > > > Documentation is somewhat sparse compared to some other APIs. Mostly > inline kerneldoc comments in the core functions. It would be nice to > improve things. The modesetting API is very similar to the xrandr > API in the xserver. > > At the moment a device specific surface manager (Xorg ddx, or some > other userspace lib) is required to use kms due to device specific > requirements with respect to memory management and alignment for > acceleration. The kms modesetting ioctls are common across all kms > drm drivers, but the memory management ioctls are device specific. > GEM itself is an Intel-specific memory manager, although radeon uses > similar ioctls. TTM is used internally by radeon, nouveau, and svga > for managing memory gpu accessible memory pools. Drivers are free to > use whatever memory manager they want; an existing one shared with a > v4l or platform driver, TTM, or something new. > There is no generic > userspace kms driver/lib although Dave and others have done some work > to support that, but it's really hard to make a generic interface > flexible enough to handle all the strange acceleration requirements of > GPUs. All of the above unfortunately says to me that the KMS API has a fairly tightly coupled set of userspace components, because userspace applications need have details about the specific underlying hardware embeeded in the application to effectively use the API. If so, that's not really conducive to getting application developers to write applications to the API, since applications will get tied to specific sets of hardware. Lack of documentation on the API for userpace application writers to use exacerbates that issue, as there are no clearly stated guarantees on device node conventions ioctl's arguments and bounds on the arguments expected error return values behavior on error return and meaning of error return which are mandatory, which are optional how to perform "atomic" transactions Behavior of other fops: Are multiple opens allowed or not? Is llseek() meaningful? Is poll() meaningful? Does final close() deallocate all memory objects? sysfs nodes location expected names data formats how compliant or not any one driver is with the KMS APIcontrol where drivers are permitted to behave differently and where they are not What include files do user space applications need to include What device nodes should be opened? $ ls -al /dev/dri/* crw-rw----+ 1 root video 226, 0 2011-02-09 17:27 /dev/dri/card0 crw-rw-rw-. 1 root video 226, 64 2011-02-09 17:26 /dev/dri/controlD64 What's the difference between them? What's the renderDnn node that can show up? Which of the below are mandatory for a KMS driver to support? Which are optional? Which were bad ideas and are deprecated? #define DRM_IOCTL_MODE_GETRESOURCES DRM_IOWR(0xA0, struct drm_mode_card_res) #define DRM_IOCTL_MODE_GETCRTC DRM_IOWR(0xA1, struct drm_mode_crtc) #define DRM_IOCTL_MODE_SETCRTC DRM_IOWR(0xA2, struct drm_mode_crtc) #define DRM_IOCTL_MODE_CURSOR DRM_IOWR(0xA3, struct drm_mode_cursor) #define DRM_IOCTL_MODE_GETGAMMA DRM_IOWR(0xA4, struct drm_mode_crtc_lut) #define DRM_IOCTL_MODE_SETGAMMA DRM_IOWR(0xA5, struct drm_mode_crtc_lut) #define DRM_IOCTL_MODE_GETENCODER DRM_IOWR(0xA6, struct drm_mode_get_encoder) #define DRM_IOCTL_MODE_GETCONNECTOR DRM_IOWR(0xA7, struct drm_mode_get_connector) #define DRM_IOCTL_MODE_ATTACHMODE DRM_IOWR(0xA8, struct drm_mode_mode_cmd) #define DRM_IOCTL_MODE_DETACHMODE DRM_IOWR(0xA9, struct drm_mode_mode_cmd) #define DRM_IOCTL_MODE_GETPROPERTY DRM_IOWR(0xAA, struct drm_mode_get_property) How does one iterate through multiple properties or all they all returned at once? The amount of data returned by drm_mode_get_property seems unbounded as the caller provides some pointers cast to __u64. How is the caller supposed to know how much space to reserve? Is the method consistent across all drivers? What is a property? Any random (name-tag, value) pair the driver wants to provide? Are there any required properties consistent across all drivers? #define DRM_IOCTL_MODE_SETPROPERTY DRM_IOWR(0xAB, struct drm_mode_connector_set_property) #define DRM_IOCTL_MODE_GETPROPBLOB DRM_IOWR(0xAC, struct drm_mode_get_blob) #define DRM_IOCTL_MODE_GETFB DRM_IOWR(0xAD, struct drm_mode_fb_cmd) #define DRM_IOCTL_MODE_ADDFB DRM_IOWR(0xAE, struct drm_mode_fb_cmd) #define DRM_IOCTL_MODE_RMFB DRM_IOWR(0xAF, unsigned int) #define DRM_IOCTL_MODE_PAGE_FLIP DRM_IOWR(0xB0, struct drm_mode_crtc_page_flip) #define DRM_IOCTL_MODE_DIRTYFB DRM_IOWR(0xB1, struct drm_mode_fb_dirty_cmd) If we ask application developers to "read the kernel source and figure it out", who is really going to write any userland code to that API? X and Wayland developers. What userspace application developer is going to crosswalk all the drivers and figure out what is universally supported by all the kernel drivers, versus what is intel, radeon, or nouveau driver specific? What are the userspace applications currently using KMS: the Xserver, Plymouth, and Wayland? Any others on the horizon? > kms does however provide a legacy kernel fb interface. That's another reason I had initally looked into it for replacing the ivtv X-driver. I figured moving ivtvfb over to the DRM/KMS FB implementation interface could be a first easy step. > While the documentation is not great, the modesetting API is solid and > it would be nice to get more people involved and working on it (or at > least looking at it) Does solid mean it is not going to change? > rather than starting something equivalent from > scratch or implementing a device specific modesetting API. It is too difficult for me to say if it would be equivalent. The one issue that often springs to mind is the security policy. Video capture and presentation devices may require different user permissions than the Desktop, and console VTs. If using a common API means both Console and Video devices now have to have the same security policy; requires someone to get new, elevated privileges; or now means joe-user can DoS the graphics memory system, then it is not worth it just for that. > If you > have any questions about it, please ask on dri-devel (CCed). I've posed some of them both rhetorical and genuine. Regards, Andy _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
