[haiku-development] Re: New Screen Pref
- From: Fredrik Modéen <fredrik@xxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Thu, 12 Jul 2007 14:44:41 +0200 (CEST)
>
> Fredrik Modéen wrote (2007-07-12, 13:48:02 [+0200]):
>>
>> > Hi Fredrik,
>> >> >> I was thinking of making some changes in to the screen pref. Like
>> >> >> adding support for NVidia card the same way Radeon card has but UI
>> >> >> found some comments that the radeon implementation was bad and
>> >> >> BeOS/Haiku didn't have any good implementation for duel monitors.
>> >> >>
>> >> >> So what have to be done to native support duel monitors? What will
>> >> >> break that we don't have the source to?
>> >> >>
>> >> >> I would like to develop on Zeta will that brake?
>> >> >>
>> >> >> First thing that comes to mind after reading the screen pref code
>> >> >> and DualHeadSetup_0.04 are that the struck display_mode must be
>> >> >> expanded and the lib that will be broken are libbe.so right?
>> >> >>
>> >> >> Can this implementation be made such way that Zeta/BeOS are not
>> >> broken
>> >> >> perhaps only need new/updated drivers?
>> >> >
>> >> > Obviously nothing will be broken if you implement what was already
>> >> > there on
>> >> > R5/ZETA. The Screen preflet can do what DualHeadSetup did before,
>> >> > that would break nothing. The additional options were communicated
>> >> > to the driver
>> >> This are what I found in Screenwindow.cpp and it look's like screen
>> >> pref only supports duel monitors/tv out on Radeon.
>> >
>> > [...]
>> >
>> > yes, it says that, but please have a look at the DualHeadSetup
>> > application source if it doesn't use the same protocol after all. Have
>> > you confirmed that? If it does not use the same protocol (ie same
>> > additional flags defined for the display_mode flags), then your next
>> > option is to change the
>> > nvidia driver to do use the same protocol. :-)
>>
>> Yes I did and it uses
>> /*dualhead extensions to flags*/
>> #define DUALHEAD_OFF (0<<6)
>> #define DUALHEAD_CLONE (1<<6)
>> #define DUALHEAD_ON (2<<6)
>> #define DUALHEAD_SWITCH (3<<6)
>> #define DUALHEAD_BITS (3<<6)
>> #define DUALHEAD_CAPABLE (1<<8)
>>
>> ah now I get it.. think, the uint32 flags are set and then alterd
>> depending on action / state ()
>
> Yes.
>
>> to realy show my knowlage, what are these doing (0<<6) , (1<<6) etc? to
>> me it's ether 4 char's like in a define message or a bit operation.
>
> Those are bit operation. I don't think "0<<6" will do any good. However,
> it
> seems that DUALHEAD_BITS are the bit positions in the uint32 flags which
> control the dual head behaviour of the nvidia driver.
>
> I will try to explain:
>
> #define FIRST_BIT (1)
> #define SECOND_BIT (1<<1)
> #define THIRD_BIT (1<<2)
>
> these macros use the shift operator to set an individual bit on in a
> value.
> It is equivalent to doing this:
>
> #define FIRST_BIT 0x0001
> #define SECOND_BIT 0x0002
> #define THIRD_BIT 0x0004
>
> but the first variation is more readable with regards to which bit is on.
>
> #define DUALHEAD_ON (2<<6)
>
> should be the same as
>
> #define DUALHEAD_ON (1<<7)
>
> and
>
> #define DUALHEAD_BITS (3<<6)
>
> should be the same as
>
> #define DUALHEAD_BITS ((1<<6) | (1<<7))
>
ok the first part I understand :) but 2<<6 same as 1<<7.
> ---
>
> In any case, this "protocol" means that the Screen preflet or the
> DualHeadSetup application use previously unused bits in the "flags" of the
> display_mode structure, to communicate with the graphics driver. You just
> need to find out if the radeon driver (multimon.h) and the nvidia driver
> (DualHeadSetup) use the same bits to mean the same thing. If they do, the
> protocolls are compatible, and you simply need to change the Screen
> preflet
> to accept the nvidea driver like the ati driver and show you the
> additional
> interface. If they are not compatible, you need to find out if you can
> change the nvidia driver so that they are compatible.
the screen pref has
enum {
SHOW_COMBINE_FIELD = 0x01,
SHOW_SWAP_FIELD = 0x02,
SHOW_LAPTOP_PANEL_FIELD = 0x04,
SHOW_TV_STANDARD_FIELD = 0x08,
};
I gues that this are the part we was talking about
and I found this on the pref app
RADEON_MODE_MULTIMON_REQUEST
I will have to do more digging when I have the source/are in other OS than
windows.
>
>> So.
>> - Radeon have some dirty private header that it calls and works today i
>> Screen pref.
>> - Nvidia have som extra flags atached to display_mode.flags
>> the app server don't support more than one screen as it can only return
>> the ID for B_MAIN_SCREEN_ID
>> "In the current implementation, there is only one display
>> (B_MAIN_SCREEN_ID). "
>> then again the DualHeadSetup has this text.
>> "Note please that the current relatively complicated solution exists
>> only
>> because BeOS/Zeta/Haiku do not support native dualhead modes at this
>> time. Once they do the drivers will be rewritten to behave as
>> 'completely' seperate drivers 'per head'. This will make the current
>> 'custom' solution nolonger applicable."
>>
>> so implementing it as it are in DualHeadSetup would be to prefere as it
>> does not interfere with drivers that much (I think)
>
> Yes.
>
>
> Best regards,
> -Stephan
>
>
--
MVH
Fredrik Modéen
Other related posts:
