Announcement

Collapse
No announcement yet.

More Work On Red Hat's Wayland Project

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • 89c51
    replied
    i have a question regarding eagle (if anyone knows)

    from what i can understand by reading stuff around the net eagle is an egl implementation for mesa


    will gallium (when OpenGL ES is implemented as stated here) make it obsolete??? (or i understood the whole thing wrong?)

    Leave a comment:


  • elanthis
    replied
    Originally posted by Vighy View Post
    And performance will suck
    source: http://www.kernel.org/pub/linux/docs/lkml/#s15-3
    Taking advice from quotes from 5+ years ago about problems encountered 17+ years ago by people who were never knowledgeable C++ programmers is pretty stupid. C++ has no problems with kernels or performance on any sane compiler when being used by any sane developer. Anyone thinking otherwise has their head up their arse, and that fully includes Linus and company.

    Leave a comment:


  • Vighy
    replied
    Originally posted by Ze.. View Post
    Personally I'd love to see a c++ OS project doing a microkernel and using a linux driver compatibility layer for a lot of hardware support at the start. It'd be doable and interesting but wouldn't be useful for a long time.
    And performance will suck
    source: http://www.kernel.org/pub/linux/docs/lkml/#s15-3

    Leave a comment:


  • Ze..
    replied
    Originally posted by elanthis View Post
    I guess in theory it would remove the additional context switches from dispatching window events and stuff, but then to really get any advantage you'd need to move the whole WM and Compositor into the kernel.
    Then you end up moving everything into the kernel and ending up with a single address space instead of virtual memory.
    Originally posted by elanthis View Post
    Really, the only reason modesetting, memory management, and command submission belong in the kernel is because the kernel _needs_ them to be able to reclaim control of the display. The kernel has zero use for window management, window event dispatch, or so on, so there is absolutely no need for those functions in the kernel.
    The alternative is to go to a micro-kernel based operating system and a lot of these issues disappear (others come up though).

    Personally I'd love to see a c++ OS project doing a microkernel and using a linux driver compatibility layer for a lot of hardware support at the start. It'd be doable and interesting but wouldn't be useful for a long time.

    Leave a comment:


  • elanthis
    replied
    Originally posted by bridgman View Post
    Not sure I agree. Once you put modesetting, memory management and command submission into the kernel you don't gain much from moving anything else down.
    I guess in theory it would remove the additional context switches from dispatching window events and stuff, but then to really get any advantage you'd need to move the whole WM and Compositor into the kernel.

    And, honestly, there's no guarantee that would actually make any noticeable difference besides having a more crash-happy and insecure kernel. The only time I feel any latency in Linux desktop stuff is when X is doing a bunch of rendering/blitting work because my video chipset still lacks EXA/GL acceleration.

    Really, the only reason modesetting, memory management, and command submission belong in the kernel is because the kernel _needs_ them to be able to reclaim control of the display. The kernel has zero use for window management, window event dispatch, or so on, so there is absolutely no need for those functions in the kernel.

    Leave a comment:


  • bridgman
    replied
    Not sure I agree. Once you put modesetting, memory management and command submission into the kernel you don't gain much from moving anything else down.

    Leave a comment:


  • lmax
    replied
    Why not put Xserver into kernel? Linus should consider..

    As a service in user space, xorg can NEVER be efficient as WinXP.

    Leave a comment:


  • Vighy
    replied
    what can we learn through Wayland?

    What X could gain from it?

    Leave a comment:


  • TechMage89
    replied
    Quartz might be messed up under the hood, but at the very least, they built it from scratch, based on what they needed, and based on what modern hardware can do.

    X still has the problem that much of its internals are based on decades-old assumptions of needs, and trying to fix all that while maintain compatibility and continuity is a serious challenge.

    I would welcome of new X implementation. Even neglecting the benefit of being able to build on a new, clean, codebase and not have the cruft and legacy code that have plagued Xorg, having choice is good, even for something as fundamental as an Xserver.

    Choice is very useful in open-source software, and having choice in an Xserver might be helpful. Wayland, alas, is not quite it. (Although it is an interesting project in its own right.)

    Leave a comment:


  • puelocesar
    replied
    Originally posted by Zhick View Post
    Srsly,I bet Quartz is just as messed up under the hood as Xorg is.
    Well, it can be, we don't know, but at least it works WAY better! Faster and more lightweight too

    I was horrified when I installed a Hackintosh on a Celeron D, using a VESA driver and it was much faster (2D at least) then my linux box, and it also could do shadows, transparency, scale and all these 2D fancy things without any lost of performance..

    Don't get me wrong, freedom in linux and openness of the platform is much better then all that lock-in and arrogance from Apple, but we have to admit they really do nice graphics

    Leave a comment:

Working...
X