On Wed, Mar 05, 2014 at 12:46:04PM -0500, Ilia Mirkin wrote:> I actually checked this out last night, grabbed the BT869 datasheet. > Basically you'd have to implement something similar to the ch7006 > driver (see drivers/gpu/drm/i2c), which provides an API for setting > modes (the BT869 appears to have 8 of them, of which I'm guessing only > 4 are actually usable, probably the RGB ones).The 8 "modes" are just predefined sets of values, baked into the chip for easier setup. There's basically an unlimited number of "modes", with any resolution or overscan, subject to timing constraints. Think modelines, but with more values and different registers. BTW, the RGB modes only make sense if you have a special kind of connector. The PAL and NTSC modes are the ones that are normally used on those cards.> The stuff about overscan/etc are exposed as KMS properties (which in > turn appear in xrandr) and not specific to the BT869.The problem is that there's no good way to just say "I want this overscan" and then get a valid set of register values, because of the timing constraints. Nvtv includes a sort of "calculator" that tries to calculate a collection of sets of sensible values as close to a desired overscan as possible, but you still have to check (and tweak, if necessary) every of those sets to see if it actually works.> The i2c driver is supposed to expose a ->mode_set() function, which > takes a drm_display_mode.We had this discussion on the xorg mailing list back then, I think even before there was kernel mode setting. In short, xrandr properties and X-style modelines are just not enough to be able to program the BT/CX chip sensibly. You need a different infrastructure. As I said, as a workaround one can use a number of predefined modes baked into the kernel. That's better than no support at all, but not as good as being able to program the BT/CX chip freely. And then there's the Philips TV encoder chip, which has a similar freedom in programming. Of course, given that analog TVs are dying out, the question is how much effort one should put into this whole thing in the first place. - Dirk
Dirk Thierbach <dthierbach at gmx.de> writes:>[...] >> The stuff about overscan/etc are exposed as KMS properties (which in >> turn appear in xrandr) and not specific to the BT869. > > The problem is that there's no good way to just say "I want this > overscan" and then get a valid set of register values, because of > the timing constraints. Nvtv includes a sort of "calculator" that > tries to calculate a collection of sets of sensible values as close > to a desired overscan as possible, but you still have to check (and > tweak, if necessary) every of those sets to see if it actually works. >It's been quite a while since the last time I messed about with this code, but the TV encoders we already support (chrontel and nvidia's) have similar limitations, and IIRC we solve it by doing two different things: 1. We don't actually set the exact mode passed by the user. Instead, the mode (both the CRTC mode and the final output mode) can be adjusted to the "closest" supported mode compatible with the hardware, given the specified properties. 2. For some properties (e.g. the TV standard) where making small adjustments to the "virtual" mode exposed to the user wouldn't work, (e.g. because the changes would involve changing the display width/height), we change the list of supported modes which is returned to userspace in response to a property change.>> The i2c driver is supposed to expose a ->mode_set() function, which >> takes a drm_display_mode. > > We had this discussion on the xorg mailing list back then, I think > even before there was kernel mode setting. In short, xrandr properties > and X-style modelines are just not enough to be able to program the > BT/CX chip sensibly. You need a different infrastructure. > > As I said, as a workaround one can use a number of predefined modes > baked into the kernel. That's better than no support at all, but not as > good as being able to program the BT/CX chip freely. >The current model doesn't require the encoder driver to have a predefined list of modes -- it's just highly recommended if you don't want to force the user to input mode lines manually. You just need some means to compute the optimal timings algorithmically given the connector properties and a rough description of the mode. Sure, using a fixed list of modes from which you pick the "closest" to the user's settings might be the easiest way to achieve that on some chips [ch7006 does precisely that IIRC], and that might be a slight underuse of the flexibility of some hardware, but the API doesn't force you to do that.> And then there's the Philips TV encoder chip, which has a similar freedom > in programming. > > Of course, given that analog TVs are dying out, the question is how > much effort one should put into this whole thing in the first place. > > - Dirk > > > _______________________________________________ > Nouveau mailing list > Nouveau at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/nouveau-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 229 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/nouveau/attachments/20140306/a0040037/attachment.pgp>
On Thu, Mar 06, 2014 at 12:00:28AM +0100, Francisco Jerez wrote:> The current model doesn't require the encoder driver to have a > predefined list of modes -- it's just highly recommended if you don't > want to force the user to input mode lines manually.If there was a way to have the user input the equivalent of mode lines for the BT chip, full support would be easy (and I would have probably done it at some stage in the past). But the X infrastructure just concerns itself with CRTC modelines (and later on added xrandr properties), which are not enough.> You just need some means to compute the optimal timings > algorithmically given the connector properties and a rough > description of the mode.Which is the difficult part for the BT chip. While some of the timing constraints are known, others are not. Also, there's no "optimal" solution, what the calculation routine in nvtv does is to compute several "close" solutions and let the user pick one. And sometimes they are not even particularly close. Also, as I said, the solutions with very little overscan sometimes don't give a stable image or no image at all. So calculating optimal timings in the kernel without user interaction is not feasible. Unless you somehow discover the missing timing constraints. Even the size of the internal FIFO is not known.> Sure, using a fixed list of modes from which you pick the "closest" > to the user's settings might be the easiest way to achieve that on > some chips [ch7006 does precisely that IIRC],The Chrontel chips only have a very limited number of modes in the first place. But even then it makes sense to have more flexibiliy. For example, you can take one of the 800x600 modes with almost no overscan border, chop off the bottom and right and recenter shifting the sync procesessing, and that gives you a nice 768x576 mode for watching DVDs.> and that might be a slight underuse of the > flexibility of some hardware, but the API doesn't force you to do that.Give me a way to pass a block of two dozen or so values to the chip in addition to a CRTC modeline that is not checked for the usual constraints, and give the user a way to specify these values in the config file or let them choose one from a predefined list, and full support is easy. - Dirk