Hi, >>>> #define QXL_MODE_EX(x_res, y_res) \ >>>> QXL_MODE_16_32(x_res, y_res, 0), \ >>>> - QXL_MODE_16_32(y_res, x_res, 1), \ >>>> - QXL_MODE_16_32(x_res, y_res, 2), \ >>>> - QXL_MODE_16_32(y_res, x_res, 3) >>>> + QXL_MODE_16_32(x_res, y_res, 1) >>> >>> Why do you leave orientation = 1 in? Just to keep the size above 4K? >>> Shouldn't we just hardcode the rom size to 8k instead? Then assert that >>> everything fits into 8k? Or even better add a compile time check? >>> >>> While being at it it might be a good idea to move the mode table to a >>> fixed, large enougth offset (say 0x4096), so it doesn't move around >>> again in case we extend QXLRom one more time. >> >> This solution is breaking backward compatibility like Yonit pointed >> out. The fact that I can't produce a user that would break because of >> this doesn't prove there is no such user. I suggest we go back to the >> original patch I posted, breaking it into two like you requested. What >> do you say? > > Ping?
I think I've answered this one already. It is still not clear to me how this orientation thing is supposed to work and what exactly we loose when we drop those modes from the list. I havn't found a way to activate a portrait mode (orientation == 1,3) in the windows guest. Orientation isn't used anywhere in qxl (other than rom initialization), so in case the guest activates a mode with orientation != 0 spice server (and thus spice client) isn't notified about that. So spice client wouldn't rotate the display according to the guests orientation. Hmm? And finally only prehistorical 0.4.x spice guests (which use SET_MODE) can pick modes with orientation != 0. The QXLSurfaceCreate struct has no orientation field ... cheers, Gerd
