Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Class: Projector
#1
General Discussion

[INDENT]This thread is for discussion of the Projector device class. Projectors, for the most part, are very similar to the TV device class, however they have special needs enough to warrant their own device class. Given that they aren't very complex, in terms of this device class anyway, the overhead for a separate class isn't great.

The biggest difference between projectors and TVs, in general, is that projectors are much heavier weight devices, which often have high output and generate lots of heat. They therefore often require a warm up and cool down phase, to get the bulb up to working temperature on startup and down to safe levels before the fans can be turned off.[/INDENT]

Fields provided
[INDENT]Fields in this device class are in the form:

PROJ#fieldname

PROJ# indicates that it is part of the Projector device class and the fieldname part is defined below for each required field. There are no multi-unit considerations for projectors.
  • AspectRatio. This is a read/write field used to set the aspect ratio the projector should use. Projectors usually provide various aspect ratios to fit content of different shapes onto the available screen shapes. This MUST be a String field with an enumerated limit that lists the available aspect ratios. No pre-defined list is really practical, so client code MUST look at the values available in the field limit and present that list to the user. See below for a discussion of limited projector functionality wrt to AR.
  • OpAspectRatio. This MUST be a read-only string field used to indicate the current operating aspect ratio. See the comments below for why there are two fields. This one MAY have an enumerated limit but doesn't have to and generic client code shouldn't expect one.

Because some projectors have an asymmetrical set of settable vs. current aspect ratio settings, this class defines two separate fields. The AspectRatio is used to set an AR mode. And it always shows the last mode written to it, i.e. the last mode set. The OpAspectRatio is the current operating AR mode, which may be different. The reason being that some settable modes are 'auto' type modes, and they will result in a different actual operating AR.

If the projector allows you to read the current mode, then upon startup just store that in both fields. After that, only update the operating mode to show the current operating mode as reported by the projector. The settable mode field should only be updated via writes from the clients, and represents the last settable mode that was set. The exception would be if the projector actually exposes both modes separately and they are readable. In that case, then update both fields using reported values from the projector. Probably few would do this.

If the projector doesn't allow you to read the current mode, then include an Unknown value and set the operating AR field to that upon startup. Set the 'set' AR field to something reasonable initially. When clients set the mode by writing to Aspect ratio, just store that value in both fields as the currently set and operating modes. That's the best you can do. The driver MUST document this limitation. DO NOT include un-settable values in the set field, such as Unknown, since these are presented to the user to select from.
[/INDENT]

Multi-Unit Considerations
[INDENT]There is really no reasonable chance that there will ever be multi-unit concerns for projectors. [/INDENT]

Power Management Issues
[INDENT]Any drivers that implements this class MUST also implement Power.

Devices of this type typically use the full capabilities of the Power class. For many devices the PWR#Status field is a formality and all power transitions have occurred before the write to the PWR#Power fields has even returned, but in this case that's generally not going to happen. It will update the PWR#Status field as it goes through any warm-up or cool-down periods and eventually getting to the Ready or Off states requested.

[INDENT]* If a projector supports a standby mode, that is something outside of this device class and must be provided by driver specific functionality if the projector supports it. From the Power class' standpoint it would be considered Off.[/INDENT]
[/INDENT]

Backdoor Commands/Queries

[INDENT]There are none at this time[/INDENT]
Dean Roddey
Software Geek Extraordinaire
Reply
#2
(reserved for expansion)
Dean Roddey
Software Geek Extraordinaire
Reply
#3
(reserved for expansion 2)
Dean Roddey
Software Geek Extraordinaire
Reply
#4
(reserved for expansion 3)
Dean Roddey
Software Geek Extraordinaire
Reply
#5
How far do you intend to go with projector support commands? On mine there a large number of options that are only ever used during set up. For every day use I would suggest.

Power - not just on/off. Because of problems with the high power bulb, my JVC has Off, Standbye, WarmingUp, On, and Cooling.

Source Select

Aspect Ratio - 4:3, Zoom 4:3, 16:9 etc.

Vertical Stretch - Used with an external amphromorphic lens for Cinemascope 2.35:1 projection.

You could also add focus, zoom and horizontal and vertical shift to align the image with the screen, but I think this would be OK with the remote control.

PJG
Reply
#6
In the Epson driver I simulated WarmUp/Cooldown with a configurable timer to prevent damage.

For the Epsons it is typically:

Power
Lamp Life
Source
Aspect
Colormode/Filter
Wuench
My Home Theater/Automation Website

[THREAD=5957]BlueGlass CQC Config[/THREAD]
[THREAD=10624]Wuench's CQC Drivers[/THREAD]
Reply
#7
Keep in mind that these aren't limiting functionality, only defining common functionality. If your projector has special needs, the driver can expose those. It just won't be through the generic interfaces, so it won't be portable to other projectors necessarily.

We could of course represent warming/cooling cycles, and if a projector doesn't need it, it can just simulate those by setting them for a couple seconds and then moving on.
Dean Roddey
Software Geek Extraordinaire
Reply
#8
OK, took a whack at this one. Does that seem reasonable?
Dean Roddey
Software Geek Extraordinaire
Reply
#9
pjgregory Wrote:How far do you intend to go with projector support commands? On mine there a large number of options that are only ever used during set up. For every day use I would suggest.

Power - not just on/off. Because of problems with the high power bulb, my JVC has Off, Standbye, WarmingUp, On, and Cooling.

Source Select

Aspect Ratio - 4:3, Zoom 4:3, 16:9 etc.

Vertical Stretch - Used with an external amphromorphic lens for Cinemascope 2.35:1 projection.

You could also add focus, zoom and horizontal and vertical shift to align the image with the screen, but I think this would be OK with the remote control.

PJG
Thinking about this in the context of defining a my theater it isn't the projector that has these commands, logically it is the room. As an example, my aspect control and source select occur in a Lumagen Radiance video processor, for others it will be an AV processor or receiver. In fact, I may have the ability to select video processing in the AV receiver, but because of how I am wired I never change the AV receiver input (since it gets HDMI audio from the video processor) so I really will not want to see the receiver source controls exposed in the rooms user interface. Similarly, the projector has multiple inputs, but I don't want them to change either. I believe this all points to more customization being needed during the room level configuration even with the driver standards.
Mark Stega
Reply
#10
There are definitely two different levels going on. There's 'user level logic' (even if that logic is being generated for you), and there's how does user level logic interface with devices. No matter how the user level logic decides it wants to deal with AR, it needs a way to find available AR controls, present them for selection, and interact with them, hopefully all in a way that is as generic as possible.

Of course, in this case, it can't be completely generic since you might change your hardware, or re-deploy a solution elsewhere, and the AR control will move to another device. Saliva, as those French people say. This device classification stuff can only do so much. But, that so much will be a huge benefit, even if there is still another level of complications that exist above it still (and there always will be.)
Dean Roddey
Software Geek Extraordinaire
Reply


Possibly Related Threads...
Thread Author Replies Views Last Post
  Class: Thermostat Dean Roddey 17 4,064 01-29-2016, 10:15 AM
Last Post: Dean Roddey
  Class: SceneCtrl Dean Roddey 20 2,524 03-31-2015, 12:38 PM
Last Post: Dean Roddey
  Class: Irrigation Dean Roddey 8 1,318 01-28-2015, 12:09 PM
Last Post: Dean Roddey
  Class: NowPlaying Dean Roddey 8 1,303 09-23-2014, 02:01 PM
Last Post: Dean Roddey
  Class: Switcher Dean Roddey 9 1,432 08-20-2014, 08:17 AM
Last Post: Dean Roddey
  Class: Security Dean Roddey 33 4,196 08-13-2014, 03:02 PM
Last Post: Dean Roddey
  Class: Lock Dean Roddey 5 946 07-31-2014, 01:24 PM
Last Post: Dean Roddey
  Class: ContactClosure Dean Roddey 7 1,077 07-31-2014, 10:14 AM
Last Post: Dean Roddey
  Class: DIO Dean Roddey 7 1,297 07-31-2014, 10:08 AM
Last Post: Dean Roddey
  Class: Relay Dean Roddey 4 870 07-31-2014, 09:56 AM
Last Post: Dean Roddey

Forum Jump:


Users browsing this thread: 1 Guest(s)