Bug 235050

Graphics work is a team effort. Someone playing solo on the sidelines can be quite counter-productive as we've seen several times in the recent past. How about co-operating with the team instead so we can make productive, positive changes? I would suggest starting with improving your attitude towards fellow community members.

Comment 2 Jan Beich 2019-01-21 18:47:20 UTC

If you can manage on your own then fine. No need to be rude.

(In reply to Johannes Lundberg from comment #1)
> Graphics work is a team effort.

Why the badge color is so important? I have no trouble working together with others e.g., bug 221540 + bug 222175. Unfortunately, every time I've tried to engage the graphics team they've pushed me back. Sometimes the pushback resulted in rubberstamp but that's barely better than no review.

> Someone playing solo on the sidelines

I've filed bugs, asked for testing and provided feedback for others. Was that a mistake?

> How about co-operating with the team instead

I've asked for review, often weeks in advance to get the maintainer more time. Was that a mistake?

> so we can make productive, positive changes

What if you don't e.g., when repeatedly promising to review later?

> improving your attitude towards fellow community members.

Thanks, I know it could be better. When are you going to stop treating "maintainer timeout" as an attack on the team?

> The graphics team appears to push everyone on modesetting(4x), neglecting this port and its users.

This sentence is both rude and condescending. It shows lack of respect for fellow community members and this PR show no willingness to co-operate with the graphics team. I'm sure you know that we're undermanned with limited time since it's volunteer work so why not work with us instead of against us?

Why is Jan still not *on* the team? How are the teams even formed? Who decides who's on what team?

If the team doesn't have time, why not either expand it or give some maintainerships away to reduce the load on the team? Or both? If you don't have the time to review and commit everything, letting go of some control is a good idea.

(In reply to Greg V from comment #4)

As you know the graphics/input stack is a big interconnected beast and often things need to be coordinated, hence the need for a team that communicate and cooperate. "Outsourcing" parts to individuals who do their own thing without coordination is a recipe for disaster when it comes to *committing* changes. Like the recent LLVM/Mesa disaster that cost the team hours of double work.

We are undermanned and welcome more members. You don't have to be developer, doc writers, testers, anyone's welcome. You and Jan definitely qualify. There's no gate keeper that decides who can join. If you feel you have something to contribute and want to help, you're welcome to join. In fact, Jan has been invited several times.

(In reply to Jan Beich from comment #0)
Just a point of clarification.  The reason behind encouraging use of modesetting is due to the upstream Xorg team adopting that as their go-forward driver for Intel i915.  I have also read that work on the xf86-video-intel driver is also being deprecated.  

So I don't think anyone is "pushing" people in one direction or another, it's just a realistic assessment of how to best use limited resources that will help the largest set of users.  I'm sure updates to Intel wouldn't be turned down IMHO.

Comment 7 Jan Beich 2019-01-24 12:47:41 UTC

(In reply to pete from comment #6)
modesetting(4x) is slightly slower than SNA from xf86-video-intel and is part of xorg-server which haven't been updated for years. Let's ignore those.

My main gripe with modesetting(4x) is stutter and sometimes flickering on redrawing GL applications. As I use multimedia/mpv on a separate workspace modesetting(4x) causes A/V desync almost always. Quickly switching to/from a workspace with glxgears archieves the same effect. Obviously, Wayland (Sway) is not affected.

Changing drm-kmod version to 4.20, 4.16, 4.11 or 4.9 doesn't help. I'm on Skylake and suspect Intel may have ironed out modesetting(4x) support in later iGPUs e.g., Icelake won't support legacy drivers (xf86-video-intel or libva-intel-driver).