Opened 15 years ago

Closed 15 years ago

#4144 closed bug (fixed)

BScreen::SetMode() not working OK

Reported by: rudolfc Owned by: axeld
Priority: normal Milestone: R1
Component: - General Version: R1/pre-alpha1
Keywords: Cc:
Blocked By: Blocking:
Platform: All

Description

In the Bebook, this function is described: status_t SetMode(display_mode* mode, bool makeDefault = false); It does not work in Haiku: the call is never made to the accelerant.

What does work in Haiku is this (which is used in Haiku's screen preflet):

SetMode(workspace, &mode, false);

This problem exists for a long period of time now, upto/including R31786. Newer ones are not tested.

Change History (9)

comment:1 by stippi, 15 years ago

Could you please check with hrev31864? It should have fixed the problem.

comment:2 by rudolfc, 15 years ago

Hi Stephan,

The good news is Setmode is now executed. However: the flags are not all 'transparantly' used as BeOS does. The officially unused flags are filtered on Haiku, while BeOS handles all bits.

The behaviour on Haiku is that it seems Setmode only accesses the accelerant if the mode differs from the already set one. If only (unknown)flags are different it won't call the accelerant, nor will it save them for the next boot. The app_server dedraws the screen however as a 'proof' Setmode is actually called from the app. Can it be proposemode also is not transparant for all flags?

The setmode command with the workspace argument seems to react the same as the 'normal' setmode command: so in that sense setmode is now fixed.

Anyhow: I am talking about the flags since the Matrox and nVidia drivers use these flags for dualhead and TVout support. It would be handy if that would be possible on Haiku, saves me some time rewriting the driver for the Haiku screen preflet at this time..

Please let me know if the flags will be modified to behave like BeOS or not. :-)

Bye and thanks for the quick response!!

Rudolf.

comment:3 by rudolfc, 15 years ago

Bug #4052 is 'the same' as this one BTW.

Rudolf.

comment:4 by stippi, 15 years ago

Rudolf, may I encourage you to look into app_server to get this fixed yourself? It seems everyone is busy with something else, and Haiku development usually works this way. I know from experience that one can be reluctant to dig into other peoples code to get something accomplished, but it's most often the only way in the end. Otherwise you have to wait for "somebody" to get around to code this for you, but "somebody" may not even have the facilities to test the changes properly or know what to look out for. For example, I have only one screen, and I don't even have a setup with a driver that supports dual screen at the moment. Don't be afraid of app_server code, it's seen a few iterations of rewrites and refactoring. It should be fairly clean and at least be easy to follow the code so you know where the changes should go, and in this particular case, all you have to fix is the proper storage of some flags value. You probably have this going in an hour or two.

The classes you want to look at are:

  • ServerApp (get's the screen mode change command)
  • Desktop and VirtualScreen (know the current screen mode)
  • AccelerantHWInterface (calls into the accelerant)
  • DesktopSettings (for persistency)

Hope this helps.

comment:5 by rudolfc, 15 years ago

Hi Stephan,

Thanks for your confidence in me :-) So. I plan to comment out this line since it's incompatible to BeOS: BScreen::SetMode(): Screen::SetMode(const display_mode& mode, bool makeDefault)

line:

current.flags = mode.flags

should not be there.

If all is right, SetMode is only issued by the app_server upon workspace switches if and when the modes differ: even if only by a flag! If a mode differs even by a single bit the accelerant _should_ be called to handle this.

If you don't object, I'll kill that line above.

Rudolf.

comment:6 by rudolfc, 15 years ago

Stephan,

About persistency: the error sits in VirtualScreen.cpp: mode.flags are not saved in StoreConfiguration().

Also AddScreen() does not retreive the flags (of course). It should, and it should issue the (Be) Setmode(mode, persistency) function, after it itself setup the entire mode, instead of only the pieces.

I _could_ modify this to do that, but I am not confident I won't detroy something, or maybe I need to also adjust stuff in other files I don't know about??

I'd be more in piece of mind if you or someone else who really knows what he's doing would do that instead..

Bye!

Rudolf.

comment:7 by stippi, 15 years ago

Hm, but I think you know what you are doing. If you don't feel confident in commiting the fix, you could at least attach a patch here. If you cannot see any regressions in your testing after doing these changes, but stuff that didn't work before suddenly works, then it's an improvement, no? :-D

comment:8 by rudolfc, 15 years ago

Ok, ok. You've convinced me. I'll give it a try, test it, and commit it. Next week. After all, if my style isn't very nice (or something), you can always correct me.. :)

Thanks again!

Rudolf.

comment:9 by rudolfc, 15 years ago

Resolution: fixed
Status: newclosed

Hi,

Since R32212 BScreen mode.flags handling is fixed. DualheadSetup now works as expected. Closing ticket.

Bye!

Rudolf.

Note: See TracTickets for help on using tickets.