- Debugger: Getting mixed signals
- 'Packaging Infrastructure' Contract Weekly Report #4
- Haiku monthly activity report - 06/2015
- 'Packaging Infrastructure' Contract Weekly Report #3
- 'Packaging Infrastructure' Contract Weekly Report #2
- GCI 2014 winners trip report (mentor side)
- TeX Live and LyX; Changes to the boot code
- 'Packaging Infrastructure' Contract Weekly Report #1
- Beginning of 'Packaging Infrastructure' Contract
- Haiku monthly activity report - 05/2015
WebKit weekly report #42
Hello world!
This week most of my time was spent on preparing the 1.4.3 release of HaikuWebkit. This fixes more bugs and removes the "tiled" rendering mode introduced in 1.4.0, which turned out to not work so well. Some old drawing issues will make a comeback, however, and I will need to dig into the app_server clipping code again to understnad what's happening there and actually fix them.
Yesterday my new machine was delivered. I'm now the owner of a Core-i3 4330 based machine, which I will use for Haiku and WebKit development. This machine has two cores with hyperthreading, and is much more modern than my aging laptop. It's currently cloning the WebKit repo. I'm keeping my laptop as well so I can use both machines at the same time to do multiple big compilations in parallel.
Anyway, this isn't the only reason I bought this machine. With all the talk on the mailing lists about Haiku not supporting any modern hardware, I wanted to try things for myself and see what it was really like. This machine features UEFI, USB3 ports, but also legacy PS/2 and COM ports so I have a way to use KDL if that's needed.
I'm currently booting in "legacy" BIOS mode and not making use of the USB3 ports. However this morning I added support to our drivers for the CPU integrated video, and I now have the machine running at native resolution. Addingthis was just a matter of putting the PCI IDs in the driver, something that only takes a few minutes. So if you have hardware that only boots in VESA mode, please take the time to open a ticket and include a complete listdev output. Maybe there is a similar easy fix for your hardware, but with no bug report, we have no way to know if that would work.
On this new machine I'm also getting some short mouse stalls (the cursor stops moving for one or two seconds, then resumes). I'll be investigating this as I'm not the only one with this problem and there's a ticket for it. And I will have a look at our UEFI support too, now that I can actually test it.
Sound and network worked out of the box, as well as the SD card reader installed in the machine. So I'd say our modern hardware support is actually not that bad at all, and easy to improve if people take the time to report their problems on the bugtracker so our devs can try to fix them.
Of course I'm also continuing the work on WebKit2 and fixing the remaining drawing issues in the current WebKit1. I'll try to get WebKit2 to display some pages to see if it has the same problems.
- PulkoMandy's blog
- Login or register to post comments
Comments
Re: WebKit weekly report #42
Happy to see you received the new machine!
I hope you are able to push a HaikuWebkit which can render the whole page text soon. Also hoping you can help with UEFI support so we can boot Haiku on Mac easily...
I didn't see the lazy mouse issue on my machine.
Re: WebKit weekly report #42
PulkoMandy,
It is great that you are taking a risk and installing Haiku on a new (and untested) system. It is also excellent that you picked a middle range system for continuing your development work as this will keep the "hardware requirements" for the HaikuWebKit in the middle range as well.
I also hope that your suggestion about how best to keep the Haiku development team aware of what work/does not work with Haiku will greatly help improving the perception of Haiku having adequate hardware support.
Re: WebKit weekly report #42
The tiled rendering mode sounds like it was a useful experiment, however, I remember when you first blogged about it, the way you described it working sounded as if it was an experiment to see whether it can be a way of climbing over and around some rendering issues (maybe partially to confirm where the rendering issues actually are as well as experimenting with the tiling speed without acceleration). At the time I wanted to comment (but didn't have password to hand) to say that I'm not sure that it would actually get rid of the visual corruption long term - because the slightly faster 2D drawing path was still producing that corruption or not drawing properly underneath. I was worried that if the experiment worked, there might be a temptation for devs to ignore the path that led to visual corruption and that it might be burying the problem. I imagine that the remaining reasons as to why there are some missing elements on the screen (when not using tiled rendering) is related to edge cases within the supporting 2D drawing code. I don't have enough experience looking at Haiku's code to say for sure but that's what I suspect... that said, if it is the case then you probably already knew that.
Re: WebKit weekly report #42
Re: WebKit weekly report #42
"Maybe there is a similar easy fix for your hardware, but with no bug report, we have no way to know if that would work."
Actually you easily could do, particularly because Haiku has this crude 1980s-style‡ probe-based hardware detection. Drivers which you suspect will work for as-yet unknown to you hardware can be modified to optionally (say, based on the Boot menu settings) try to use this hardware and emit a notation in the system logs. In the probe routine, match the known common parameters (e.g a PCI device with an Intel vendor, classed as a Display Controller sub-type VGA compatible) and if this boot-time option is set, treat it as one of the known types as a last resort.
In a more modern OS design the work would be broader in scope and thus more capable (e.g. Linux runtime driver binding) but for Haiku everything is delegated to the driver probe routines because that's how BeOS did it twenty years ago. So the only code you need to modify to enable this feature is in the driver itself.
The other thing Haiku can and should do is track the information provided by the vendors. A company like Intel doesn't want to launch a new chipset and have it not work anywhere, so they do announce this stuff with PCI IDs and so on in advance. Obviously they can be secretive about the exact specifications, but it's not as though Haiku depends on bleeding edge features, or indeed for video hardware anything beyond mode setting. There is no technical reason why Haiku can't incorporate these updates as others do rather than waiting for one of a handful of developers to see the hardware with their own eyes as you've done.
-
‡ In the 1980s we had to walk to school and it was uphill both ways. Also, most computers including PCs did not have an intelligent expansion bus able to report the installed devices, so for optional devices it was necessary to gently "probe" for each possible device to see if it was present, hopefully without disturbing other hardware. Today most of Haiku's probe routines are just pointlessly masticating data fed from an intelligent bus. IIRC Axel began work to modernise this aspect of Haiku but it remains unfinished and largely abandoned.
Re: WebKit weekly report #42
Huh? We actually have two driver architectures, the device manager, and the legacy drivers for BeOS compatibility. Many drivers still use the legacy one, granted, but the primary one is actually used, too (for example, all storage and ACPI drivers (except USB) are using it). The legacy driver architecture is working just fine, that's why the pressure is low to convert the existing drivers. Once power management comes into play, this will likely change, though.
In any case, the work you need to do to identify the devices you want to work on is always pretty much the same, no matter how you express it. The only difference is that either the kernel knows which device your driver is using, or not (the kernel has to load all drivers in any case to know this, it may however cache this information for future use).
The main benefit of the non-1980 approach (which is a stupid assessment, anyway, seeing how far ahead other bus systems were in the 80s compared to ISA) is that the kernel can prevent multiple drivers claim the same resources.
Re: WebKit weekly report #42
In any case, the work you need to do to identify the devices you want to work on is always pretty much the same, no matter how you express it. The only difference is that either the kernel knows which device your driver is using, or not (the kernel has to load all drivers in any case to know this, it may however cache this information for future use).
Nope. Didn't I discuss this with you before? Or was it another Haiku developer?
Anyway. Neither Linux nor NT do this. Once you stop thinking in terms of probe routines you can express hardware support declaratively and you don't need to "load all drivers", you can just consult an index of supported hardware and choose the right driver (if there is one) directly.
Imagine you're visiting a library, perhaps at a university. You want a book about World War II era Allied military intelligence, and one about the CP/M operating system.
Now, certainly Haiku's way to solve this problem, simply strolling around the library from one bookcase to the next methodically removing every book from the shelves and examining it to see if it's one of those desired is uh... effective?
But I suggest that a much better plan would be to consult the library catalogue, which most likely can point you to almost the pinpoint location of suitable books immediately, and will certainly avoid a lot of wasted time in the event that the library simply doesn't have those books at all.
Re: WebKit weekly report #42
If you have a better way, you're free to implement it yourself, are you not? There are two ways of solving an issue - one is complaining about it and pointing out a different way and another is doing it. One is often more effective than the other.
Re: WebKit weekly report #42
In any case, the work you need to do to identify the devices you want to work on is always pretty much the same, no matter how you express it. The only difference is that either the kernel knows which device your driver is using, or not (the kernel has to load all drivers in any case to know this, it may however cache this information for future use).
Nope. Didn't I discuss this with you before? Or was it another Haiku developer?
Anyway. Neither Linux nor NT do this. Once you stop thinking in terms of probe routines you can express hardware support declaratively and you don't need to "load all drivers", you can just consult an index of supported hardware and choose the right driver (if there is one) directly.
Imagine you're visiting a library, perhaps at a university. You want a book about World War II era Allied military intelligence, and one about the CP/M operating system.
Now, certainly Haiku's way to solve this problem, simply strolling around the library from one bookcase to the next methodically removing every book from the shelves and examining it to see if it's one of those desired is uh... effective?
But I suggest that a much better plan would be to consult the library catalogue, which most likely can point you to almost the pinpoint location of suitable books immediately, and will certainly avoid a lot of wasted time in the event that the library simply doesn't have those books at all.
Haiku cold boots faster then linux/windows, really, that is all I care about. If two solutions or even more then two solutions exist, then live and let live. As I have said in the past, if you like Linux so much, why are you here, don't you have some linux zealots to go high 5 and stuff ?
Re: WebKit weekly report #42
Not sure if you just play dumb. I'm pretty sure that Linux still has to open the module to be able to know the PCI devices its supports (but please correct me if I'm wrong). Windows puts this stuff into the registry -- but either way, that's exactly what this "cache this information" is all about; once the kernel knows which driver supports which device, it can store that information, and doesn't have to search for it next time.
Where it gets that information from is largely irrelevant; if we really wanted to, we could even find out about that for legacy drivers as well: it could call its probe method with a proxy PCI tree that only ever contains a single device at a time. The kernel has everything to select the correct driver directly, it just doesn't make use of that information yet (patches welcome).
In any case, I'm not a fan of putting that information outside of the driver. Each module should be self contained.
Re: WebKit weekly report #42
I agree - drivers are addons, you can load in another one (in theory) without having to inform the rest of the kernel. That is a good enough reason for me...
Re: WebKit weekly report #42
Not sure if you just play dumb. I'm pretty sure that Linux still has to open the module to be able to know the PCI devices its supports
It's even better than that, the kernel doesn't care at all. This is a policy decision and so it's surfaced to userspace. That has other advantages too. For example, if you plug a USB inkjet printer into some modern Linux distributions the userspace code informed about the new device will realise it's a printer and prompt the user to agree to the installation of the OS package containing specific printer drivers for that model off the network if they don't have them already. If you don't ever use an HP printer, you don't need all the baggage that comes with running one.
but either way, that's exactly what this "cache this information" is all about; once the kernel knows which driver supports which device, it can store that information, and doesn't have to search for it next time.
Indeed.
Where it gets that information from is largely irrelevant; if we really wanted to, we could even find out about that for legacy drivers as well: it could call its probe method with a proxy PCI tree that only ever contains a single device at a time. The kernel has everything to select the correct driver directly, it just doesn't make use of that information yet (patches welcome).
When you say that the current Haiku kernel "has everything to select the correct driver directly" can you elaborate, try using the "device manager" AHCI driver as your example because that gives a flavour of the complexity hidden under this thin crust.
In any case, I'm not a fan of putting that information outside of the driver. Each module should be self contained.
The declarative design doesn't have to make the driver modules any less self-contained. The usual design of a Linux driver for say, a PCI device is to have the driver refer to literally the same table of PCI device parameters at runtime in ring 0 as the one used outside the kernel to generate the index of supported devices. This saves space on disk and in RAM, and was an elegant iterative improvement over earlier designs in which the same table was used (as happens in Haiku) only at runtime.
But all this rather gets way from the point of my original comment, Haiku doesn't have to wait for somebody to paste PCI device lists into a ticket to make this better. The Haiku developers, including Adrien, could make this relatively modest change and let end users do more of the work.
Re: WebKit weekly report #42
if you plug a USB inkjet printer into some modern Linux distributions the userspace code informed about the new device will realise it's a printer and prompt the user to agree to the installation of the OS package containing specific printer drivers for that model off the network if they don't have them already. If you don't ever use an HP printer, you don't need all the baggage that comes with running one.
With haiku, you simply plug the printer in, goto the printer prefrences and select the printer driver and model. Though I think that should be simplified, it comes with the printer drivers already installed via guetenprint
Re: WebKit weekly report #42
Other than being able to map device IDs to drivers (which is always possible), this has nothing to do with what we talked about. The kernel needs to select and load drivers long before the userland exists.
The PCI bus manager will publish all devices as nodes. Depending on the type of nodes, the kernel will choose the drivers to load. In the case of a storage device, it will scan the available storage drivers, and ask each if it supports that particular device. If it does, it publishes another node that is attached to the device node. At that point, the driver is no longer in use, and might be unloaded again.
The kernel could store this mapping, and just ask that particular driver first on the next boot. This is just not implemented yet.
As you hopefully understand from what I wrote above, it simply cannot usually work this way, but only for a fraction of the drivers. And again, the only thing needed to make this possible is to know if a device is already controlled by a driver or not. Haiku currently only knows that for device manager devices, but not for legacy driver devices (which could be solved if we really wanted to, as outlined earlier).
I don't see much of a practical difference. Even for the declarative method you still have to load the module into memory, you still have to parse and relocate it; of course, you can also retrieve that information from userland, then, but why should that be important?
Re: WebKit weekly report #42
Other than being able to map device IDs to drivers (which is always possible), this has nothing to do with what we talked about. The kernel needs to select and load drivers long before the userland exists.
All Linux kernel modules are inserted from userspace. Drivers that need to run very early must be compiled into the kernel itself, because of course there isn't yet anywhere else to load them from. Once this very early stage is over, the kernel uses a netlink socket to send events to userspace, and userspace tools take whatever action they deem appropriate in response. That could be anything from inserting a PCI driver to, in the example I gave, launching a GUI offering to install printer drivers.
This is of course quite a contrast to Haiku, where much of the system policy is explicitly determined by developers like yourself through hard-coding behaviour in the kernel and could only be changed by forking Haiku.
The kernel could store this mapping, and just ask that particular driver first on the next boot. This is just not implemented yet.
This certainly is just a cache as you originally described and not really a means to avoid loading and interrogating all the drivers about every new piece of hardware. I suppose I couldn't have expected more.
As you hopefully understand from what I wrote above, it simply cannot usually work this way, but only for a fraction of the drivers.
As I wrote above, this is not only possible for the vast majority of drivers, it's how it's actually done right now on millions of Linux systems. There are 85 modules currently inserted into the Linux kernel of the laptop where I've been writing most of this. These were all inserted by modprobe, on behalf of udevd, a systemd component that monitors the netlink socket I mentioned earlier (of course I could manually insert more, but I haven't needed to do this for years and most users would never need to, nor know how). The policy enforced by udevd is written as text files, although of course you could replace udevd altogether - or omit it entirely if you're designing an embedded product with no expansion or upgrade capability.
The driver modules loaded include those for my gigabit ethernet, WiFi, graphics, bluetooth, camera, SD slot, and even an old-school parallel port. Indeed the declarative approach is very broadly applicable. For example the model of CPU used in the laptop has a built-in temperature sensor. This fact is exposed as a CPUID feature bit, and the kernel reports those bits when describing the CPU over the netlink socket. So the driver module for that temperature sensor is inserted along with everything else.
I don't see much of a practical difference. Even for the declarative method you still have to load the module into memory, you still have to parse and relocate it; of course, you can also retrieve that information from userland, then, but why should that be important?
Policy. See above.
Re: WebKit weekly report #42
That would be a huge step backwards from where Haiku is now. However, I thought the graphics drivers were included in this as well. Are you sure that udev is running that early? The initial mode set happens pretty fast in any case.
Pardon my ignorance, but I don't see the point of udev at all. I also see actually no connection between the outcome that you described, and the design of udev. Why on earth should any user service decide where my device is published, anyway?
Just to give you an idea of how it would work on Haiku: you attach a USB hard drive to your system. The kernel identifies the device (and its driver), and publishes the device for userland use. Some userland service listens for device changes, and will then auto-mount that disk's partitions. You attach a USB printer. The kernel does not have a driver for it. A userland service listening for device changes notices the new printer, loads a userland driver, and configures it.
What is it that those great policies give you? The possibility of changing the outcome? Did you ever need this? Why would you ever need this?
Re: WebKit weekly report #42
That would be a huge step backwards from where Haiku is now.
Hahaha. Well Haiku will certainly not be making any huge steps, eh? In any direction.
Pardon my ignorance, but I don't see the point of udev at all. I also see actually no connection between the outcome that you described, and the design of udev. Why on earth should any user service decide where my device is published, anyway?
Indeed? Well if it's all about your device we can hardly argue. But I suppose the people who donated enough money to pay Adrien's grocery bills think it is for their devices too.
But we actually got into this discussion in a way that's illustrative. In Linux binding a driver to a device at runtime from userspace is something udevd could do if asked to.
Re: WebKit weekly report #42
Actually I had the same lazy mouse problem with my Asus M5A97 EVO R2.0
- First of all I noticed the bug only when I was using WebPositive
- By enabling the IOMMU in BIOS the problem seemed to be less aggressive
- By removing one of my video cards the problem vanished (I have a Matrox G550 PCIe and a S3 Chrome 20, I kept Matrox one that has its own accelerator)
I'll open a ticket about this