From nobody Wed Jan 5 12:16:02 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 938B51938C38 for ; Wed, 5 Jan 2022 12:16:12 +0000 (UTC) (envelope-from sblachmann@gmail.com) Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JTT3c3Nj5z3JMs; Wed, 5 Jan 2022 12:16:12 +0000 (UTC) (envelope-from sblachmann@gmail.com) Received: by mail-lf1-x129.google.com with SMTP id u13so88532438lff.12; Wed, 05 Jan 2022 04:16:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=6sOO156XX54eIDDpQBIKWmR3aCLKtmo1pZGJ5xyXxYI=; b=YePaATXKMp6r8zlUKu3N7G9tqfJl0VC0IQXgHghtCUPQ9xuW7B7m/FBBXLUwhsohV+ ClLXd0h0KqynpeYvdrB+P8mpdIr/sVTyK0EiUH/A6Hx6dFBrp9pofC/iG1T9JKSZ/oea 373+HcQWrWF2/DKUD1qlU14K4BoH63X0icftZ8CGUSNI6rG9QRN3fyDDfdjjzHeCPzIP 1FP/w2kJqytLMUJXkJBNFSgQfw9p6ObRrrRucBY7ERsNWRRC/r5/tdNGm5ezLx+X4LcX +NHEDTMwA5dEctZUDXO773FJP6PMP5EQV4M7+34iZC1+AFnjlwxG00p1H5Fybt+iJn1W /sQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=6sOO156XX54eIDDpQBIKWmR3aCLKtmo1pZGJ5xyXxYI=; b=PYpbposQgfjPbsfpVLNpv1s5Z6VSx/aaQlr7Y+lBOiiKLvo1Vcd4wgqs5yHLk9mETU 1fCv57FjG6aY6kw0ZDkkj4jgHU0cgqdEI72jp47ZpCtfsUHAfSNYaX7H9F4rAVkwpV3h kEA5R1z395Mk0UPsBtMVfNbN6lf5gedEr2DCO6sp4BRBWM7Y5Xzq1HBXqPs59udx01bO bbwT2eYI+nGfZCSvAWkycLAa2zZzXkpFZzEfNY6MrgXjUG/hdyVTxhqaCU97T+ptEVxp lgM/P3Vzm2l4BYRNruHc6fOwF2kaqQ7DUrcw2LKo0wjgWxSwtGDVo38vAtZgS/xeCQWW hb7A== X-Gm-Message-State: AOAM533B7ndrGPJJVV9P3D0Lt8AF+EltizinGGqdT649JGYXG9B4rg0b Me4Nw4AOxgWVat259sKsIHoFWNaUZ36MHYyJj1U= X-Google-Smtp-Source: ABdhPJzEsj2+AQUdqVdZxUNiwVfcJAMnNszTff+6N/uzEUFMNBprrGSeg8aj4NI4uHHDQbY3E99Ae3pX1mb5LsGDkDs= X-Received: by 2002:a05:6512:234d:: with SMTP id p13mr41676761lfu.157.1641384963777; Wed, 05 Jan 2022 04:16:03 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Received: by 2002:a2e:920a:0:0:0:0:0 with HTTP; Wed, 5 Jan 2022 04:16:02 -0800 (PST) In-Reply-To: References: <861r36xzpe.fsf@phe.ftfl.ca> <61100a28-40ae-4458-d7d5-3bc9b13ba219@gmail.com> <864k6qj6x6.fsf@phe.ftfl.ca> <86zgoihs64.fsf@phe.ftfl.ca> From: Stefan Blachmann Date: Wed, 5 Jan 2022 13:16:02 +0100 Message-ID: Subject: Re: Call for Foundation-supported Project Ideas To: Warner Losh Cc: Joseph Mingrone , =?UTF-8?B?w5Z6a2FuIEtJUklL?= , Michael Schuster , Kyle Evans , Karel Gardas , FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4JTT3c3Nj5z3JMs X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; TAGGED_RCPT(0.00)[]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On 1/4/22, Warner Losh wrote: > 15 or 20 years [...] > main reason laptops stopped suspending in the early 2000s... [...] > And the INT xx interface is unavailable on amd64 after we > enter long mode First, you mentioned a hacking session in the "early 2000s". This makes me wonder whether you might mistake some other thing from the distance of time, as UEFI was no real thing until ~2010, and was never a thing on platforms other than amd64 also. Suspend/resume on FreeBSD only appeared much later, too. Second, there is kernel functionality to call real mode interrupt handlers from long mode, which manage switching to real mode and back. Just an example, these are being used by vt (via vesa.ko) to switch vesa mo= des. So I do not see why this real mode access infrastructure could not also be used to make a call to C000:(PCI PROM Programming interface code offset), or the respective segment address where the actual VGA BIOS is, to have it initialize the int 10h interface handler, if a hybrid/dual graphics card BIOS is present. I think a single function "InitializeVGABIOSifpresent" to enable access to VGA/VESA BIOS functionality might actually be fairly easy to implement. Furthermore, there is no need at all to access hardware specific stuff like you mentioned, as the necessary functionality is completely covered by the int 10h interface. Imho it could be worth to allocate a small part of the sponsoring budget to put a bounty to motivate people (including possibly me) to implement these improvements regarding suspend/resume and enhanced sc and vt usability. On 1/4/22, Warner Losh wrote: > On Tue, Jan 4, 2022 at 12:14 AM Stefan Blachmann > wrote: > >> On 1/4/22, Warner Losh wrote: >> > Not without loading the xorg graphics stuff... graphics chips from the >> last >> > 15 or 20 years have lots of chip specific state that only the graphics >> > stuff knows about... IIRC, it only knows about it because it put the >> > graphics into a known state... it's the main reason laptops stopped >> > suspending in the early 2000s... it looks to be a lot of work for a >> > relatively rare use case... >> >> UEFI GOP seems to have the necessary functionalities >> (https://wiki.osdev.org/GOP#Get_the_Current_Mode) so I guess the work >> required would be limited (restore mode and redraw screen from >> buffer). >> > > UEFI GOP isn't available after we start the kernel, so this is a > non-starter. > It works great in the boot loader, but not so good after we boot. It coul= d > work > for S3 sleep to disk where we actually reboot to restore the machine stat= e, > but we don't have sleep to disk today :( > > >> With non-UEFI or old UGA UEFI implementations possibly one could use >> the dual BIOS=C2=B4 CSM part. Just call the CSM BIOS init to set up GPU = and >> the int 10h interface, and then set previously used mode+redraw. >> BTW, doing that also could both enable vt(4) to change >> modes/resolutions and using sc on UEFI computers. >> > > Ah, if only things were really that simple... I tried variations on that > hack years ago when suspending broke due to video. And it > works for some machines, but not others, was the quick assessment > I made. And the INT xx interface is unavailable on amd64 after we > enter long mode (I tried this out on my then-current FreeBSD laptop > which was 32 bit only, so 15 years ago?). > > Warner > > >> But I think you are right, there are probably not too many users who >> would make use of that. >> >> >> On 1/4/22, Warner Losh wrote: >> > On Mon, Jan 3, 2022, 11:03 PM Stefan Blachmann >> > wrote: >> > >> >> Implementing S3 suspend/resume was a sponsored project itself. >> >> However, it still does only work when at xorg graphics mode, which >> >> already was topic in this thread. >> >> When using it from console, no matter sc or vt, it still hangs with >> >> dark screen and unresponsive keyboard. >> >> Could finishing the suspend/resume work be sponsored, so that it also >> >> works on console-only computers? >> >> >> > >> > Not without loading the xorg graphics stuff... graphics chips from the >> last >> > 15 or 20 years have lots of chip specific state that only the graphics >> > stuff knows about... IIRC, it only knows about it because it put the >> > graphics into a known state... it's the main reason laptops stopped >> > suspending in the early 2000s... it looks to be a lot of work for a >> > relatively rare use case... >> > >> > Warner >> > >> > >> >> On 12/30/21, Joseph Mingrone wrote: >> >> > On Thu, 2021-12-30 at 14:15, Joseph Mingrone >> >> > wrote: >> >> > >> >> >> On Thu, 2021-12-30 at 08:05, =C3=96zkan KIRIK >> >> >> wrote: >> >> >>> I've ideas about enhancing the routing architecture. Is it >> >> >>> possible >> >> >>> to >> >> >>> add to wiki? >> >> > >> >> >> Certainly. Please do. >> >> > >> >> > The link again is https://wiki.freebsd.org/2021FoundationCFI >> >> > >> >> >> >> >> > >> >