2 สิ่งใหม่ที่จะมาใน Wayland (และไม่มีใน X)

การประกาศใช้ Wayland ของ Ubuntu ทำให้เกิดกระแสวิพากษ์วิจารณ์กันเยอะมากตามเว็บต่างประเทศ บางอันก็ดูมีเหตุผล บางอันผมก็ว่าไร้สาระ (เว็บของไทย ผมยังไม่เจอเว็บไหนวิจารณ์ในเชิงลึกเลย ส่วนใหญ่ก็บ่นกะปอดกะแปดกันไปตามเว็บบอร์ด ถ้าใครเจอบทความภาษาไทยดีๆ เกี่ยวกับ Wayland ช่วยแนะนำกันด้วยนะครับ) ส่วนใหญ่ก็จะเถียงเรื่อง Wayland ดีไม่ดี คุ้มไม่คุ้มที่จะเปลี่ยน

เรื่องดีหรือไม่นี่ ผมว่าหลายคนคงจะหายข้องใจกันไปเยอะแล้ว Wayland มันก็น่าจะมีดีพอตัวแหละ ไม่งั้น Fedora คงไม่ประกาศใช้ Wayland ด้วยหรอก (–> ข่าวจาก Blognone)

เหลือสิ่งที่เป็นกังวลมากๆ ก็คือคำถามอย่างหลังนี่แหละ มันจะคุ้มไม่คุ้ม? เพราะอย่างที่ผมเคยบอกไป การเปลี่ยนมาใช้ Wayland ทุกโปรแกรมที่อิงอยู่กับ X จะต้องเขียนกันส่วน GUI ใหม่หมดเลย ของใหม่เจ๋งๆ ที่จะมีมา Wayland มีอะไรบ้าง ยังคงเป็นเรื่องที่ค่อนข้างลี้ลับอยู่ในตอนนี้ ส่วนใหญ่ก็จะรู้กันแค่ว่ามันเล็กกว่า เร็วกว่า ไม่เทอะทะอุ้ยอ้ายเหมือน X ที่แต่ละคนแปะโปะโบ๊ะเพิ่มฟีเจอร์ต่างๆ เข้าไปมาตลอด 20 ปีที่ผ่านมา

Phoronix เว็บที่โปร Wayland เยี่ยงเสื้อแดงโปรทักกี้ ได้เสนอข่าวเกี่ยวกับ 2 สิ่งที่จะมาแน่นอนเมื่อ Wayland เสร็จสมบูรณ์ และสองสิ่งนี้ไม่มีใน X (และอาจจะไม่มีไปอีกนาน) นั่นคือ

อย่างแรก คือ GPU switching ผมว่าแค่อันนี้อันเดียวก็คุ้มแล้วแหละ สิ่งนี้คือสิ่งที่ผู้ใช้ Linux เรียกร้องหากันมานานแสนนาน ใน Wayland เครื่องที่มีการ์ดจอออนบอร์ดกับการ์ดจอแยกจะสามารถสลับใช้การ์ดจอแต่ละอันได้ โดยไม่ต้อง restart Wayland

ลองไปฟังปากคำเกี่ยวกับเรื่องนี้จาก mailling list ของ Jerome Glisse นักพัฒนา Wayland ตรงๆ เลยดีกว่า (เพราะผมก็ไม่รู้จะอธิบายยังไงเหมือนกัน)

Outcome of discussion between Dave, Kristian, Jesse and me while riding a bus is that we should add a way for wayland to ask its client to redraw their surface using a another EGL driver and that wayland server should be able to handle client reporting failure doing so. Maybe i did get this wrong, feel free to correct me 🙂

I think to cover all use case Dave presented we should have somethings like this:

– wayland provide a list of EGL driver it can texture from (optimus case where we can migrate texture from nvidia to intel)
– wayland can ask to it’s client to switch GL driver and report if they can switch or not (i think this should happen in 2 step first ask and gather answer from all client if one client says it can’t then forbid the switch, otherwise ask to all client to redraw with new driver)

All this wouldn’t need restart from wayland.

สิ่งที่สอง คือ ความสามารถในการรัน Application พร้อม Compositor เต็มจอแบบไม่กระตุก ใน X เราก็รันโปรแกรมแบบเต็มจอได้ แต่ว่าใน Wayland เนื่องจาก Compositor กับ Display manager เป็นตัวเดียวกัน การเรนเดอร์ภาพแบบเต็มจอจึงส่งคำสั่งผ่าน protocol ของ Wayland รอบเดียว ปัญหาเรื่องภาพกระตุก เม้าส์กระโดด แบบที่เคยเกิดใน X จะกลายเป็นอดีตไปเลย

ความสามารถการรันแบบเต็มจอนี้จะส่งผลดีอย่างมากต่อพวกโปรแกรมเกมส์ ซึ่งส่วนใหญ่จะเปิดเล่นแบบเต็มจอ และจำเป็นต้องมีการรับสิ่ง input-output ระหว่าง display กับ user ตลอดเวลา เหมือนกันกับอันแรกครับ ไปฟังปากคำจาก Kristian Høgsberg โดยตรงกันเลยดีกว่า

Nope, you’re spot on and I agree. Carsten Haitzler recently posted a good writeup on the good and bad things games do under X:

http://lists.x.org/archives/xorg/2010-September/051152.html

and at the end of the email he’s proposing something similar to what you describe. I even think we shouldn’t expose the full modesetting API to regular applications, just enough that they know the screen sizes and layout. Either the compositor can run a special client with access to the modesetting interface or changing the resolution and/or screen layout could just be part of the compositor.

Either way, a native resolution fullscreen mode is definitely planned. Both scaling (with or without aspect ratio/black bars) and native modes (we can page flip directly to the applications buffer) make sense, but I think that will be policy/configuration options in the compositor. What will be in the protocol will be a way to request to be fullscreen, which the compositor will honor when the application has focus, but it will always be possible to alt-tab away (or press the “home button” or similar). So the compositor is in control, it will change the resolution, scale and draw black bars, or maybe even just center the application window and fade out the rest of the desktop around it.

This also ties in with capturing the mouse pointer and relative events (which Carsten also talks about in his mail). Typically games also want to make sure the pointer stays inside the window and they want relative events. It’s no good if you’re trying to turn around in quake and the pointer leaves the window or hits the screen edge. X applications solve this by grabbing the mouse, confining it to the window and continuously warping the cursor into the center to simulate relative events. This is obviously a hack, and wayland isn’t going to support open-ended pointer or keyboard grabs, nor warping the pointer. Instead, we provide relative events when the device generates them, and in fullscreen mode, all the events go to the fullscreen application, so no need to confine the pointer. Possibly, an application can request “application pointer”, where the compositor hides the pointer when the fullscreen application receives focus, doesn’t update its location and only sends relative events. This is a pointer mode that may be useful to allow when an application has a button grab as well (that is, grabbing the pointer for the duration of a button click).

Anyway, this is all kinda half-baked, but it is the general direction I see this going.

Kristian

หวังว่าสองสิ่งนี้น่าจะพอเป็นแนวทางให้หลายคนตัดสินใจได้ว่า Wayland คุ้มหรือไม่คุ้ม

ที่มา http://www.phoronix.com/scan.php?page=news_item&px=ODc3MA